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
- [Uta] Proposed definition of opportunistic encryp… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Olle E. Johansson
- Re: [Uta] Proposed definition of opportunistic en… Stephen Farrell
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Leif Johansson
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Daniel Kahn Gillmor
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman
- Re: [Uta] Proposed definition of opportunistic en… Stephen Farrell
- Re: [Uta] Proposed definition of opportunistic en… Alan Johnston
- Re: [Uta] Proposed definition of opportunistic en… Paul Hoffman