Opportunistic Security: Some Protection Most of the Time
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org> Subject: Document Action: 'Opportunistic Security: Some Protection Most of the Time' to Informational RFC (draft-dukhovni-opportunistic-security-06.txt) The IESG has approved the following document: - 'Opportunistic Security: Some Protection Most of the Time' (draft-dukhovni-opportunistic-security-06.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/
Technical Summary This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security remove barriers to the widespread use of encryption on the Internet by using encryption even when authentication is not available, and using authentication when Working Group Summary This is an AD sponsored document and not the product of a WG. It was extensively debated on the saag list and during an extended IETF LC. The concept was also debated at the STRINT workshop. The shepherd write-up has more to say: "The document and its predecessors were discussed with great gusto over many months on the SAAG mailing list, in the UTA WG, and at two IETF meetings. There is a great deal of interest in having a common set of definitions for the ideas related ot opportunistic security, even where there might be disagreement about where it should and should not be used. The IETF Last Call on the -03 draft produced a lot of suggestions for major improvements to the language in the draft, and the author did a significant revision based on them, all without changing the design philosophy. There are probably still some people who think that the wording is not what they would want, and some who think that the whole idea is a bad one, but there was rough consensus that the document was useful and should be published. The document has had more review, and ended up getting stronger consensus for the eventual definition, than the products of many security WGs. Because this document does not define how to implement opportunistic security, there is some disagreement about its applicability to existing and future IETF protocols, but there was strong agreement that the definition was good enough for many protocols." This underwent an extended LC after work to develop -05 based on IESG and other feedback on -04. Document Quality One would not directly implement this as its a design pattern. There are Internet-drafts that are using this already in DANE, HTTPBIS and some individual drafts. Personnel Paul Hoffman is the document shepherd. Stephen Farrell is the irresponsible AD. IANA Note There is no IANA considerations section, and none is needed in this case.