Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 03 February 2014 21:42 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF841A01EE for <uta@ietfa.amsl.com>; Mon, 3 Feb 2014 13:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 O8w4KsebV7-c for <uta@ietfa.amsl.com>; Mon, 3 Feb 2014 13:42:16 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A19E61A0232 for <uta@ietf.org>; Mon, 3 Feb 2014 13:42:15 -0800 (PST)
Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 49048F984 for <uta@ietf.org>; Mon, 3 Feb 2014 16:42:14 -0500 (EST)
Message-ID: <52F00D33.3080206@fifthhorseman.net>
Date: Mon, 03 Feb 2014 16:42:11 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0
MIME-Version: 1.0
To: uta@ietf.org
References: <20140203045910.9714.53880.idtracker@ietfa.amsl.com> <B8691415-07F3-4081-8247-E103A60E5CF0@vpnc.org> <700ECF7E-253E-4CCC-BD73-6008216E5429@edvina.net> <CAKhHsXFmbc_CxPHSfzji-J7mJTUh4MOfwVFjnOdk-B+bA9miqA@mail.gmail.com> <D9374419-5EFE-455D-B348-F2698001BDF6@vpnc.org> <CAKhHsXHvme7-26MFHwsdvR-osqhy4L1dk6gZve9YR5jPduNi1A@mail.gmail.com> <52EFD1E4.6020200@fifthhorseman.net> <D8FACB55-C706-4886-9485-2A84EB90CB26@vpnc.org>
In-Reply-To: <D8FACB55-C706-4886-9485-2A84EB90CB26@vpnc.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="SVrwUWDira2NsXqMdPWhfEsK16sEDN1qo"
Subject: Re: [Uta] Proposed definition of opportunistic encryption using TLS: draft-hoffman-uta-opportunistic-tls-00.txt
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 21:42:18 -0000

On 02/03/2014 04:32 PM, Paul Hoffman wrote:
> On Feb 3, 2014, at 9:29 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
>> Opportunistic encryption as declared by the draft is encryption that
>> *will* fail against an active attacker or MiTM.  
> 
> Nope. Opportunistic encryption using TLS, as it is defined in the -00 draft, will work just fine with an MITM.

I think i wasn't clear enough about what i meant by "fail".  Thanks for
catching that.

By "fail" i meant "not protect the user's confidentiality or
authenticity".  I did not mean "cause the connection to fail".

My understanding is that an active attacker who interrupts or MiTMs an
opportunistic encryption will likely be able to succeed at reading the
content of the communication, whether it's because the peers are willing
to proceed without authentication, or because the peers are willing to
fall back to cleartext.

>> It would be bad for the
>> 'net if our tools were to indicate that MiTM-able connections are
>> "secure" using the same UI as non-MiTM-able connections.
> 
> That's true, but it is also different than "failing".

Right, and i think your specification declares this properly.

> If the WG adopts the draft and wants to change the definition, of course it can. But the current definition absolutely allows the opportunistic client to ignore the server's authentication information in order to help prevent a passive snooper from seeing the traffic.

Sure, i'm agreeing with you about this, i think.  I don't think i
proposed a change in the definition.  if you think we're in
disagreement, can you clarify where?

	--dkg