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(_at_)dcrocker(_dot_)net>
Reply-To: dcrocker(_at_)bbiw(_dot_)net
To: saag(_at_)ietf(_dot_)org <saag(_at_)ietf(_dot_)org>
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