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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 12 March 2014 21:46 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 2A5491A0685; Wed, 12 Mar 2014 14:46:59 -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 eMnFudP965WB; Wed, 12 Mar 2014 14:46:56 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2381A0733; Wed, 12 Mar 2014 14:46:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B4F37BE51; Wed, 12 Mar 2014 21:46:49 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESecBKXOHD61; Wed, 12 Mar 2014 21:46:48 +0000 (GMT)
Received: from [10.87.48.8] (unknown [86.46.16.238]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BFE6BE29; Wed, 12 Mar 2014 21:46:48 +0000 (GMT)
Message-ID: <5320D5C8.8030509@cs.tcd.ie>
Date: Wed, 12 Mar 2014 21:46:48 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <CAMm+LwjF9To+w3K4RR=72BbLNE2hJa9CibWOEARYmODiuFNu9g@mail.gmail.com> <082D04F9-DBB4-4492-BE91-C4E3616AC24D@isi.edu> <531F85D5.2070209@bbn.com> <531F8A53.1040103@isi.edu> <531F8E5F.8030705@isi.edu> <20140312062756.GN11878@anguilla.noreply.org> <3454.1394657237@sandelman.ca> <5320C932.3010107@cs.tcd.ie> <10021.1394658818@sandelman.ca>
In-Reply-To: <10021.1394658818@sandelman.ca>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3R0MtNriUUoUKPDyxufRk7xgxM8
Cc: Peter Palfrader <peter@palfrader.org>, saag <saag@ietf.org>, dane@ietf.org
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:46:59 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hiya,

On 03/12/2014 09:13 PM, Michael Richardson wrote:
> 
> Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> On 03/12/2014 08:47 PM, Michael Richardson wrote:
>>> The part that we are all discussing is determining how (much)
>>> to trust the DH results.
> 
>> I don't think that's a very accurate characterisation to be
>> honest.
> 
>> I think the most relevant (but intertwined) factors are:
> 
>> - trading off ease of deployment vs. endpoint authentication -
>> trading off protection against passive vs active attack - better
>> separating key exchange from endpoint authentication so that
>> traditional authentication or TOFU or whatever can be used before
>> during or after key exchange
> 
> But, you made my point.

Well yes and no, we're agreeing and almost but not quite
discussing the same things I figure, let's see if that
continues... :-)

> While the end user sees the overall benefit is: my traffic can not
> seen
> 
> The problems and challenges that we have are not in how or even
> when to apply AES,

Agreed.

> it's how/when to do the DH.

"How" to do DH is pretty much the same everywhere or at least
the diffs are not relevant for a generic terminology draft.

"When" is I think as-soon-as-you-can (modulo amortizing DH over
multiple "sessions" or similar).

I think our challenges are not in when to do DH but in how that
relates to when we might do what forms of endpoint authentication
(or none) and the consequences of each of those options.

That's why I think a generic terminology draft will be useful, as
there are lots of potential combinations. Naming each (or whatever)
will make it easier for protocol developers to argue about what's
suitable for their particular environments.

For example, in the limit, I think it'd be worth thinking about
whether a post-facto MITM detection protocol perhaps run a day or
two later might have value. That'd be more of a research topic
really, but could still represent a form of useful endpoint
authentication even if it only detected a MITM with say a 1%
probability. Think of Alice and Bob depositing a witness pair
derived from the DH secret and some HASH(shared-info + application
traffic) some place(s) so someone (else) could detect if there
was a Charlie in the middle. (BTW: I'm not sure such a useful
generic protocol exists, but it'd be fun to work it out.)

> To the end user, having the word "encryption" in the terminology is
> useful because it tells them why they should pay attention to it.

Good point. Maybe that's why folks keep coming back to OE
as a term.

> 
> To us, it's a red-herring, because it's not where the issue is.

Also true.

Cheers,
S.

> You listed the issues.
> 
> (BTW: my TLA cache is failing on "TOFU")
> 
> -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
> Works -= IPv6 IoT consulting for hire =-
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTINXHAAoJEC88hzaAX42iuwsH/jG+Iny/Ae5cEJblR09CD9CE
oPhLIMQM6eFBHiFFkz185XilNgyCUuWlAsGSEAMxNybKwZmpChf52ljhEXgE7Vx8
ULDHW8NadWp6O6V2CXie4vQM3ZAW58sgGRCqtejja3R2+DrKxgqi5gnWNxOYLt45
fzXjZYwZ1njlKPV1iLkAwrhLMj8HYOd005CNwW4owL746SV95AroZU316VfVVvB/
ehoLCHINcFJ32mFoPynPQwY/oSL89UWhSzswnkNljSC1R9dYs+eX/mEkBgFC/0Am
EptcQZ0IwS5nBf4IwWi9V2wD+phS9zMAcOhpT7oJPzguZhChF/ziVH0NwYGsibg=
=32vZ
-----END PGP SIGNATURE-----