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

Nico Williams <> Wed, 12 March 2014 17:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF6521A04B8; Wed, 12 Mar 2014 10:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kj3WnwFjT4ZN; Wed, 12 Mar 2014 10:06:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D9E91A04C2; Wed, 12 Mar 2014 10:06:10 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 4A58B2005D102; Wed, 12 Mar 2014 10:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=5oMYqLH9wy6D+fktRX0k rWOyZ6c=; b=SrC99ml8mRdpeNOkNCUcSlg5PhmpPiwPCa1jorcYms6wWMUDWtXF KFbRR6jSCBYsQUu8ZL5TnoT21ol5nK38H9zi0tOBL9rmbVinIsxNIJK+GJP7nr4U z64lLIbUMaKwvAzIK98T1vnyLqPGFBC8E5s2BSSVzTCjTAS2FFLWnwM=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id C9ADF2005D108; Wed, 12 Mar 2014 10:06:03 -0700 (PDT)
Received: by with SMTP id k14so9151123wgh.34 for <multiple recipients>; Wed, 12 Mar 2014 10:06:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s8I3t4SOI2QY6L/4Y3JzvRKhSwgBOqh01jJu4T85tgs=; b=mG1cjGPdfj8cafWOZvOxNcYRe1aSbYSlCaaJT9HJO0eB21p73e18yntW1/61NHeYc3 tnCqq0p670whbkikhRWd0l/jSxYNRsn/gqr7T8NHWJ092ez4Yc1BCG/LSN8i5tPUi8c1 GyouKA86OLgFBRz9MAlzzcty+FxmX4Ndt5OdTiPm7hLXLcdNN/sabVYECZNsxypIramT Q8q1UG0EXoOCOasEudvh2GJheFp5TFDakzjvpetuYlp8PmDxj1AVpp8EcbNJhYYxrJsS gdrzE0gnV/zFp3pPqhKvrMaDeINc2iKH8d3nkK0Eq+c0rpfD7kXeDMoehiFp2+4+05pU vvcA==
MIME-Version: 1.0
X-Received: by with SMTP id yk14mr8572892wib.5.1394643961958; Wed, 12 Mar 2014 10:06:01 -0700 (PDT)
Received: by with HTTP; Wed, 12 Mar 2014 10:06:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 12 Mar 2014 12:06:01 -0500
Message-ID: <>
From: Nico Williams <>
To: Joe Touch <>
Content-Type: text/plain; charset=UTF-8
X-Mailman-Approved-At: Wed, 12 Mar 2014 10:21:49 -0700
Cc: saag <>,
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:06:16 -0000

On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch <> wrote:
> On 3/12/2014 6:35 AM, Stephen Kent wrote:
>>>> 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)

OK will present difficulties as an acronym...  Otherwise I like
"opportunistic keying", but it could cover a large range of behaviors
(e.g., TOFU).

> 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.

For me the goal was to use channel binding at the application layer.
But we never got there: no one seems to care much about end-to-end
IPsec, sadly.  (Well, it's not that no one cares, but that it's too
late now; TLS is king.)

> 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.

Stephen has it right: OE in the RFC4322 sense is about applying
protection even when SPDs don't agree on this, but it still requires a
keying infrastructure (i.e., trust paths).