Re: [dane] [saag] Need better opportunistic terminology

Joe Touch <touch@isi.edu> Tue, 11 March 2014 22:12 UTC

Return-Path: <touch@isi.edu>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8675F1A0823; Tue, 11 Mar 2014 15:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaItCGUI0cLa; Tue, 11 Mar 2014 15:12:55 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7CA1A063F; Tue, 11 Mar 2014 15:12:55 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2BMCZWQ019124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 15:12:35 -0700 (PDT)
Message-ID: <531F8A53.1040103@isi.edu>
Date: Tue, 11 Mar 2014 15:12:35 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>, dane@ietf.org, saag <saag@ietf.org>
References: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com> <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com>
In-Reply-To: <531F85D5.2070209@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/IaoPSi0XcjRPNxJKlQvlSVneDWg
Subject: Re: [dane] [saag] Need better opportunistic terminology
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 22:12:57 -0000

Hi, Steve,

On 3/11/2014 2:53 PM, Stephen Kent wrote:
> Joe,
>
>> On Mar 6, 2014, at 1:23 AM, Phillip Hallam-Baker <hallam@gmail.com
>> <mailto:hallam@gmail.com>> wrote:
>>
>>> The term opportunistic has become the new synonym for 'Good' but it
>>> is being used for many different things.
>>>
>>> A) Unauthenticated key exchange
>>
>> Fwiw, this is IMO an error since I first introduced BTNS, and I had to
>> clear it up on Wikipedia multiple times. I see nothing opportunistic
>> about this mode as a stand-alone concept.
 >
> The original use of the termappears to be from RFC 4322, Micheal
> Richardson's document. He describes how to use keys retrieved from
> the DNS with IPsec/IKE, without prior, bilateral arrangements for
> access control, via the SPD. He defined OE that way, and noted that
> it was not an unauthenticated mode of IPsec.

RFC4322 defines OE.

Section 1.2 describes "anonymous encryption" which is basically 
unauthenticated key exchange.

 From later in that section:

    Although it is a useful mode, anonymous encryption is not the goal of
    this project.

Michael and I discussed the difference between the two (OE and anonymous 
encryption) on many occasions, and I don't think either of us ever 
confused the two (though someone who edited Wikipedia did once). The 
sentence above confirms that, AFAICT.

 > I prefer that we stick
> with that definition of the term, which is IPsec-specific.

I'm not quite sure what term or what definition you're referring to: OE, 
anonymous encryption, or unauthenticated key exchange. Can you clarify?

> I have
> suggested "opportunistic keying" as a preferred term, since its the
> key management, not the encryption per se, that distinguishes other
> proposed modes of operation for IPsec, TLS, etc.

I agree if you're replacing OE with OK ;-)

> The breakout group at the STRINT workshop that discussed terminology
> suggested using the term noted above.

Sorry, but to clarify, which term?

Joe