Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx
Alyssa Rowan <akr@akr.io> Wed, 12 March 2014 13:22 UTC
Return-Path: <akr@akr.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3041A0980 for <tls@ietfa.amsl.com>; Wed, 12 Mar 2014 06:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 4AD8AhMrNyjt for <tls@ietfa.amsl.com>; Wed, 12 Mar 2014 06:22:46 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7C1A0421 for <tls@ietf.org>; Wed, 12 Mar 2014 06:22:45 -0700 (PDT)
Received: from [10.69.242.136] (94.197.121.41.threembb.co.uk [94.197.121.41]) by entima.net (Postfix) with ESMTPSA id A640460B8E for <tls@ietf.org>; Wed, 12 Mar 2014 13:22:38 +0000 (GMT)
User-Agent: K-9 Mail for Android
In-Reply-To: <53205A3F.5080802@fifthhorseman.net>
References: <CAK3OfOgw70LVQsykxNZSH9+4Dn2inBTx0q0KrvujS1LOY1i9tg@mail.gmail.com> <532024EF.4060607@polarssl.org> <53205A3F.5080802@fifthhorseman.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
From: Alyssa Rowan <akr@akr.io>
Date: Wed, 12 Mar 2014 13:22:32 +0000
To: tls@ietf.org
Message-ID: <2643d802-f33b-4caf-b5e1-4df42d59814e@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uMktIepnz98Bb9wUFVGY0LM_UXI
Subject: Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_GCM_SHAxxx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 13:22:49 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 12 March 2014 12:59:43 GMT+00:00, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: >using certificates and expecting the peer to not validate them has a >couple downsides: > 0) [certificate provisioning] > 1) [TOFU complications] And an upside: An attacker in a position to MITM in TLSv1.2 would be in a position to see *_anon suites offered: and therefore heuristically guess what the peers will choose and whether an active MITM attack would likely be detected or not. That would be bad: I think we'll want to conceal that data if possible so that an attacker can't easily distinguish between opportunistic connections they'd succeed silently on (and restrict their MITM to that case, silently decrypting without tripping any warnings and staying under the radar), and authenticated connections in which MITM shenanigans would raise very loud alarm bells. Let's try to keep the "lasers" invisible to third parties, if we can? Of course if we keep this in mind for TLSv1.3 and the Hellos are encrypted in that version, problem hopefully solved, although the size of the Hello exchange might provide a side channel revealing whether certs were exchanged. Thoughts? - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.0.9 iQI3BAEBCgAhBQJTIF+YGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6jAYP/3djv/eTRe7dSzJem8jFYhpwM/PJKq+ZKLx6Kf2RGOrD0QD4r1WS zgYEPF6rK2tm8s7G4P16emKzV0/L4rk0jE3yfPm8q3+7ce3VkIqxWMiXw18gNK9q EPcSuQVm1rlLovjvXTqzWL3LVmIQpm4hpGGJ02DjJXcAl5DKyGhTG5pCGQVoyHSA 3zw1q9lD2GcvAh5d5AwXWbbxMmtE4Z5p0GWGq9xGFnYA8CSMU8QvrGhz9C071z97 /HTOZ7YpeiVcXWa4ilQ1PclGe3zJySkLgJwy4PMwOslslITb5HDYi+b7yo+7+L9t jkLIVKwfX3rI1QZavJRSVCVw49i9f/0+pYwMdZHvcM9y9BHLGOeqZw20RUxaQX7K vLs0cKvMU5JQDbWO4ZJVVZX8Q6U9ngghdD9qnetyfpQuQpihWQYsp14hiabKsFp0 UaNzeQTop7IM7Y0MFQagFbHRDPO6DK+2t+xtjiTmDW5LuxH4cpbySksum6APeYe+ 8dS6wRVosqLHotAoqdIckCkHINzfuFVM8fqRhkofGywAjuXmoC88lq50N5D+guc1 pjO8i4VP5j//nUZ011v4aGrJtV2yxh9ytluhz/fWlNNGcF0OsPliF2KwkxjbS4jd 0rV0c2n321NWyAphynLWF/g1gpC8gHD+KJ6r3e03AQh6nI/0ZTV/WU3s =S255 -----END PGP SIGNATURE-----
- [TLS] Still missing: TLS_ECDH_anon_WITH_AES_xxx_G… Nico Williams
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Manuel Pégourié-Gonnard
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Daniel Kahn Gillmor
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Alyssa Rowan
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Alexandre Anzala-Yamajako
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Yoav Nir
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Peter Gutmann
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Nico Williams
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Alyssa Rowan
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Yaron Sheffer
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Nico Williams
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Martin Rex
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Yaron Sheffer
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Nico Williams
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Nico Williams
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Kurt Roeckx
- Re: [TLS] Still missing: TLS_ECDH_anon_WITH_AES_x… Peter Gutmann