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

Stephen Kent <kent@bbn.com> Wed, 12 March 2014 21:47 UTC

Return-Path: <kent@bbn.com>
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 0E96B1A0772; Wed, 12 Mar 2014 14:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 kgEEKg7o1l0g; Wed, 12 Mar 2014 14:47:16 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2855C1A0479; Wed, 12 Mar 2014 14:47:16 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:49606 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1WNqzV-000IhX-HF; Wed, 12 Mar 2014 17:47:09 -0400
Message-ID: <5320D5DD.8060204@bbn.com>
Date: Wed, 12 Mar 2014 17:47:09 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, 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> <531F8A53.1040103@isi.edu> <53206293.8020907@bbn.com> <5320900C.2030007@isi.edu>
In-Reply-To: <5320900C.2030007@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ytb5-MW_oJ9NSrTOBQiXUC9SeOs
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: Wed, 12 Mar 2014 21:47:19 -0000

Joe,
 >
>> yeah, I like OK (and I like IKE too, for those of us old enough to
>> appreciate that election slogan)
>
> I'm still a little hesitant, thinking on it further, about the term 
> "opportunistic" in this sense at all.
>
> BTNS uses unsigned key exchanged, and there's nothing "opportunistic" 
> about it. Unsigned authentication is the goal from the start.
>
> OE as defined in RFC 4322 isn't about using unsigned key exchange; the 
> "opportunistic" sense is derived from using keys retrieved from DNS 
> without prior agreement. That's not what happens in BTNS.
agreed.
> Paul just noted:
> "Opportunistic keying does provide authentication, it's just that
> the authentication is only to the public key and is not
> tightly bound to any other type of identification (address, name, etc.)"
Public keys are not principles. We went through that long and painful 
discussion
during the SPKI days. So, saying that OE provide authentication of a key 
seems
meaningless to me, especially if the key is ephemeral.
> I.e., fundamentally, opportunistic approaches are completely different 
> from those that don't ever bother to authenticate. I don't think it's 
> useful (and could be confusing) to confuse the two by overlapping 
> terminology.
We'll, we don't have an agreed upon definition for O* yet. My view is 
that the primary goal of
this effort is to remove barriers to using encryption. Since 
authenticating the identity or a
peer or server has tended to be a barrier, we seem willing to make that 
form of authentication
optional. But, we still prefer authentication, because we'd like to 
avoid MiTM attacks. That suggests
that O* refers to techniques that emphasize encryption, prefer that it 
be authenticated, but are
willing to fall back to un-autnenticated encryption if that's thbe best 
we can do. (And to fall back
to plaintext if the peer/server is not capable of our new-fangled O*)
> I don't like the term "optimistic" either; it too implies something 
> that you "hope works". There's no "hope" associated with unsigned key 
> exchange; you do it (IMO) because you know what it is and you know its 
> impact (e.g., raising the bar of an attacker to performing a full key 
> exchange, vs. just tossing single packets like RSTs around).
I'm not wedded top either term, but I'd like to emphasize that the 
encryption process is
the same in all cases; it's the key management that's different.
>
> Is there a reason not to just call unauthenticated key exchange what 
> it is - unauthenticated key exchange?
I think we want more than that, as I described above, hence the desire 
to coin a new term.

Steve