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

Stephen Farrell <> Wed, 12 March 2014 17:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D2081A048A; Wed, 12 Mar 2014 10:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.447
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VDkYb5asc69J; Wed, 12 Mar 2014 10:04:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5F7B81A0381; Wed, 12 Mar 2014 10:04:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05402BE54; Wed, 12 Mar 2014 17:04:01 +0000 (GMT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7kz4QkdFcQMq; Wed, 12 Mar 2014 17:04:00 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id CF68BBE56; Wed, 12 Mar 2014 17:04:00 +0000 (GMT)
Message-ID: <>
Date: Wed, 12 Mar 2014 17:04:02 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Joe Touch <>, Stephen Kent <>,, saag <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] [saag] Need better opportunistic terminology
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Mar 2014 17:04:15 -0000

(again, I'd suggest one list for this if we can and the
UTA wg list, but hopefully that'll settle down when there's
an I-D, and since I'm not the boss of us anyway...:-)

On 03/12/2014 04:49 PM, Joe Touch wrote:
> Steve (et al.),
> On 3/12/2014 6:35 AM, Stephen Kent wrote:
>> Joe,
>>> ...
>>>> 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?
>> OE. I argue that OE is defined only for IPsec, because the definition
>> focuses on how to
>> avoid the need to coordinate SPD entries at each end.
> Agreed.
>>>> 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 ;-)
>> 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.

I do think we want to define that term even if we do not
want to encourage its use. It is being used and with
subtly different meanings by different folks.

> 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.
> 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.)"
> 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.
> 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).
> Is there a reason not to just call unauthenticated key exchange what it
> is - unauthenticated key exchange?

Yes. "authenticated encryption" is a term of art (AEAD etc) and
this would be confusingly close - it'd be inevitable that some
would end up saying unauthenticated encryption and thereby would
confuse the real crypto folks.

I like the OK term myself and would be happy if we landed on
encouraging its use, based on a good definition.

But I'm fine if we end up calling it squiggle, so long as we
all end up calling the same "it" that.

> If you want something pithy, maybe "Zero-ID security"?

Too close to zero-touch (which is not ad-hominem, but is
a term being used in netconf - Joe you just *have* to get
involved in that:-)


>>> The breakout group at the STRINT workshop that discussed terminology
>>>> suggested using the term noted above.
>>> Sorry, but to clarify, which term?
>> OK vs. OE.
> Thanks for the clarification.
> Joe
> _______________________________________________
> saag mailing list