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

Joe Touch <> Wed, 12 March 2014 17:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6ABF01A0552; Wed, 12 Mar 2014 10:31:31 -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 DwC5JYu8BVxv; Wed, 12 Mar 2014 10:31:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A717B1A0381; Wed, 12 Mar 2014 10:31:25 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s2CHUnnG001614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Mar 2014 10:30:50 -0700 (PDT)
Message-ID: <>
Date: Wed, 12 Mar 2014 10:30:49 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Nico Williams <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
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:31:31 -0000

On 3/12/2014 10:06 AM, Nico Williams wrote:
> On Wed, Mar 12, 2014 at 11:49 AM, Joe Touch <> wrote:
>> 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.

Having unsigned key exchange has two ultimate uses:

	- raising the bar for attacks
		above 'send a RST' but below MITM

	- providing a network-level mechanism that can be linked
	to security at higher layers

App-layer channel binding could be useful for BTNS, or for other 
approaches too (e.g., where a single key protects a set of ports).

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

TLS still doesn't protect the transport or network layers.

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

Right, but then "O" isn't quite the right term for security that avoids 
the need for keying infrastructure altogether.