> The IESG has received a request from an individual participant to make > the following status changes: > > - RFC1984 from Informational to Best Current Practice > (IAB and IESG Statement on Cryptographic Technology and the Internet) > > The supporting document for this request can be found here: > > https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ This document pertains to an especially important and difficult topic. If IETF approval of such a document is to have the utility we expect for it, we need to be clear about that intended effect, clear how the document addresses it, and clear about its robustness against misinterpretation or dismissal by those needing to attend to the document but disinclined to do so or actively interested in undermining it. The supporting document asserts consensus within the ad-hoc saag group has a number of basic problems. So the document is an individual submission but relies on purported group rough consensus that was never established. First, saag is an accidental group that had no specific, documented task for considering this draft. As such, some who might have wished to participate in thoughtful discussion of this topic had no way to know about it. Second, discussion on the list was entirely ad hoc, with no convergence and (rough) consensus processes. The only consensus-related process concerning this document was during the saag session during the IETF meeting in Prague. There was no followup on the saag mailing list or any other. Hence the supporting document's second paragraph's reasons for rejecting an effort to revise the document have no documentable foundation. As an example of the randomness of the mailing list discussions, points I raised about the reasons a revised document is needed to respond to the current pervasive monitoring concerns received no substantive responses. Making a carefully-considered (rough) consensus choice against concerns is one thing. Ignoring them completely is quite another. The relevant portions of my posting to the saag list: -------- Forwarded Message -------- Subject: Re: [saag] keys under doormats: is our doormat ok? Date: Mon, 13 Jul 2015 12:38:09 -0700 From: Dave Crocker <dhc2@xxxxxxxxxxxx> Reply-To: dcrocker@xxxxxxxx To: saag@xxxxxxxx <saag@xxxxxxxx> On 7/12/2015 5:23 PM, Christian Huitema wrote: >> So I suggest that one of the plenaries contain a capsule summary >> -- bulleted list -- of the points folk think should be made in the >> revision, and that a 'sense ofthe room' be taken during the >> plenary. > General agreement, but I would rather not call this a revision. > Maybe something like "reaffirm." It's more than reaffirm. Possibly quite a bit more. The existing document has a very strong focus on export control and sharing of keys. The current issue is backdoors, and the like. While the existing document does list the need for private keys to be private, it's not really dealt with in the surrounding text. Changing that would be a substantive, compatible addition to the existing document. Also the existing document does not contain an explicit and affirmative statement of the basic, high-level requirements on a security mechanism. The closest it comes to a statement of principle in the document is: Security mechanisms being developed in the Internet Engineering Task Force to meet these needs require and depend on the international use of adequate cryptographic technology. The sentence after that applies the above to the particulars that the document addresses: Ready access to such technology is therefore a key factor in the future growth of the Internet as a motor for international commerce and communication. "Access" was the issue of the day. Today's issue is not the same, though of course it is firmly attached to the first of the above statements. In effect, the document could benefit from discussion at a higher level and at a lower level. The higher level is a more complete statement of the purpose, benefit and necessity of effective communication privacy, and clarity about what that benefit means to users. At the lower level, the document could benefit from some pragmatics, along the lines of what Stephen has suggested: What should a working group dealing with this realm of technology do and not do? When we approve something purporting to provide a component of 'security', what basic expectations of that mechanism or system should its consumers expect from it? To put it a bit grandly, what is the 'philosophy' of security that the IETF is applying? For example, I believe the current issue hinges on an IETF belief that those who choose to do encryption should be able to control who is authorized and able to do the decryption. Also there has been quite a bit of public discussion, this time around, and the document should reflect on that activity. ... In sum, I think the revised document should: 0. Establish the current context including examples of related public contributions. One recent publication would be obvious to include... 1. Provide statements of IETF principles about the nature and requirements for privacy-related technologies, explicitly citing relevant examples that would violate this. 2. Explain every 'what' with a 'why'. For each thing claimed to be good or bad, explain the implications of ignoring the claim. 3. Give guidance that IETF efforts can use in designing new mechanisms, formats, etc. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net