Document Action: 'Opportunistic Security: Some Protection Most of the Time' to Informational RFC (draft-dukhovni-opportunistic-security-06.txt)

The IESG <> Mon, 01 December 2014 15:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 967D11A1DFA for <>; Mon, 1 Dec 2014 07:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id brWOm1tahFKX; Mon, 1 Dec 2014 07:23:18 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id AE9901A6EE0; Mon, 1 Dec 2014 07:22:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Document Action: 'Opportunistic Security: Some Protection Most of the Time' to Informational RFC (draft-dukhovni-opportunistic-security-06.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Mon, 01 Dec 2014 07:22:20 -0800
Cc: RFC Editor <>
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Dec 2014 15:23:20 -0000

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:

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

  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.


   Paul Hoffman is the document shepherd.
   Stephen Farrell is the irresponsible AD.


  There is no IANA considerations section, and none is needed 
  in this case.