Re: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
Eric Rescorla <ekr@rtfm.com> Tue, 19 November 2013 16:07 UTC
Return-Path: <ekr@rtfm.com>
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 4A8101AE031 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 BluigPSZRNg4 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:07:21 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9A31AE05C for <tls@ietf.org>; Tue, 19 Nov 2013 08:07:20 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so4141910wes.26 for <tls@ietf.org>; Tue, 19 Nov 2013 08:07:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KUnyxBIbEnoz3HWsifsqJt4G4cMk8PRblDl4Et5orNs=; b=gTPrTD15LoAzjq2GG+3rOfqdVoD0n5ZDby1/yTHFeu0xZ8wuoIE040x/WbtmSXMvra 6ondDkhSejhTV5TZBytXxD8jR8Jiy8XKgrlQHXECBrsJ/wjkZO3oDrRhWcm3q21yNinx g5UUTgcwBjJQS386GH3tEGAzf0sewdV06AiROa01eDEPrETDidcJBV/qSmBsLYvpq2uq r2KN49cq4YwZddLW6YybPFjEmccsAjNdAElA5sG7aa2dz2BXADH0U3Hx1tZDCpNDdBVg uA4YF6n0mJe+2HX3FFCkjKyEeKsbHZl+4Ekew9nBmKe+9Ls8i6xIy4yhP4DnNwd9NDfY yNXg==
X-Gm-Message-State: ALoCoQlkcJz/0pGVRCTB63A+aMqK0ZJOSwle80uYGjLsSSg+hLVa+0brsuVtNdYX7cCSWMk0cSKL
X-Received: by 10.194.23.73 with SMTP id k9mr22813626wjf.24.1384877233928; Tue, 19 Nov 2013 08:07:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 19 Nov 2013 08:06:33 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <1BFA59E4-7393-479A-A7C8-FBF2906795F6@apple.com>
References: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp> <528B63DC.3050207@gmail.com> <1BFA59E4-7393-479A-A7C8-FBF2906795F6@apple.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Nov 2013 08:06:33 -0800
Message-ID: <CABcZeBOXsAj7UZqRk50GB4enC_BzeOXe0GDTKx_bQ_G-P4kjQg@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Content-Type: multipart/alternative; boundary="047d7b5d43969612bc04eb89db3f"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
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: Tue, 19 Nov 2013 16:07:24 -0000
On Tue, Nov 19, 2013 at 7:54 AM, Michael Sweet <msweet@apple.com> wrote: > Would a practical solution be to do a TLS 1.2.1 update that: > > 1. Keeps the same TLS version in the ClientHello as 1.2, > 2. Adds new mandatory cipher suites (as needed), > 3. Adds a fast negotiation extension (as needed/if possible), and > 4. Deprecates (but does not remove) any 1.2 cipher suites we know to be > broken. > > The goal would be backwards-compatibility with TLS implementations that > support (or at least gracefully negotiate down from) 1.2. > > (IANAC (I am not a cryptographer), I just use a lot of TLS libraries and > don’t know whether this is workable…) If the version number is the challenge, we may have to do something like that. I suggest we hold off on this question until we have a better sense of what exactly we want to stuff in TLS 1.3 and which pieces of it are going to be compatible versus just switch-hitting. Best, -Ekr > On Nov 19, 2013, at 8:13 AM, Ivan Ristić <ivan.ristic@gmail.com> wrote: > > > To add to this discussion about protocol version intolerance, I've been > > tracking this problem in my SSL Pulse data set (SSL servers from the > > Alexa top 1 million). > > > > Here's what I have for November: > > > > Total servers: 163,587 > > > > TLS 1.0 intolerance 9 > > TLS 1.1 intolerance 1,388 > > TLS 1.2 intolerance 1,448 (~ 0.9%) > > TLS 1.3 intolerance 17,840 (~10.9%) > > TLS 2.98 intolerance 122,698 (~75.0%) > > > > Long handshake intolerance: 4,795 (~2.9%) > > > > It seems to me that attempting to deploy TLS 1.3 would be very > > difficult, considering how many servers are intolerant to this version > > number. And TLS 2.x would be just hopeless. > > > > Disclaimer: I have not spent as much time as I would have liked > > validating these, but I don't have a reason to believe they are not > correct. > > > > > > On 18/11/2013 19:25, Martin Rex wrote: > >> Andrei Popov wrote: > >>> > >>> Yes, the percentage if servers that can't handle TLS1.2 or gracefully > >>> negotiate a lower protocol version is diminishing, but very slowly. > >> > >> Unfortunately, I've seen a new (government mandated) Web Service usage > >> scenario deployed in 2013 where the hardware SSL/TLS accellerater that > >> is being used is TLS version intolerant to TLSv1.1 and TLSv1.2. > >> > >> > >> We really need to get rid of the dependency on > ClientHello.client_version > >> being { 0x03, 0x03 } to use protocol features that can be implemented > >> with fairly little effort in TLSv1.0, thereby obviating the need > >> for reconnect fallbacks in clients -- a "feature" that most programmatic > >> TLS clients do not have, and that is susceptible to downgrade. > >> > >> > >>> > >>> From my perspective, enabling TLS1.2 by default is necessitated > >>> primarily by security and performance considerations (e.g. a chance > >>> to negotiate AES_GCM instead of RC4). > >> > >> The interoperability problems from sending > >> ClientHello.client_version { 0x03,0x03 } are to serious and significant > >> to ignore, and the kludges (reconnect fallbacks) are to cumbersome > >> for most apps. > >> > >> The _correct_ approach would be to publish how to use GenericAEADCipher > >> record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and > >> remove the braindead "must not send this ciphersuite with client_version > >> less that TLSv1.2" from the AES-CCM and AES-GCM documents. > >> > >> > >> rfc5746 deployed with significantly less interop problems than both > >> TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246). > >> > >> > >>> > >>> However, for web browsers, enabling TLS1.2 by default means one more > >>> step in the sequence of (insecure) reconnect attempts with lower > >>> protocol versions. > >> > >> > >> Rather than bulding such kludges into Browsers, the implementers > >> should have come to the TLS WG help working on changes to TLS that > >> will make all desired TLS features work in a more backwards compatible > >> fashion than through kicking "client_version" / "protocol_version" > fields. > >> > >> > >> -Martin > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > > > > > -- > > Ivan > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] This working group has failed Watson Ladd
- [TLS] Deployment ... Re: This working group has f… Hannes Tschofenig
- Re: [TLS] Deployment ... Re: This working group h… Taylor Hornby
- Re: [TLS] This working group has failed SM
- Re: [TLS] This working group has failed Ralph Holz
- Re: [TLS] Deployment ... Re: This working group h… Hannes Tschofenig
- Re: [TLS] Deployment ... Re: This working group h… Yoav Nir
- Re: [TLS] Deployment ... Re: This working group h… Hannes Tschofenig
- Re: [TLS] This working group has failed Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Mark Nottingham
- Re: [TLS] Deployment ... Re: This working group h… Kyle Hamilton
- Re: [TLS] Deployment ... Re: This working group h… Juho Vähä-Herttua
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Salz, Rich
- Re: [TLS] Deployment ... Re: This working group h… Andrei Popov
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Watson Ladd
- Re: [TLS] Deployment ... Re: This working group h… Geoffrey Keating
- Re: [TLS] Deployment ... Re: This working group h… Michael Staubermann
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Joshua Davies
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Andy Lutomirski
- Re: [TLS] Deployment ... Re: This working group h… Kirils Solovjovs
- Re: [TLS] Deployment ... Re: This working group h… Andy Wilson
- Re: [TLS] Deployment ... Re: This working group h… Marsh Ray
- Re: [TLS] Deployment ... Re: This working group h… Ralf Skyper Kaiser
- Re: [TLS] Deployment ... Re: This working group h… Ben Laurie
- [TLS] TLS protocol version intolerance [Was: Re: … Ivan Ristić
- Re: [TLS] Deployment ... Re: This working group h… Zooko Wilcox-OHearn
- Re: [TLS] TLS protocol version intolerance [Was: … Michael Sweet
- Re: [TLS] TLS protocol version intolerance [Was: … Eric Rescorla
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- Re: [TLS] Deployment ... Re: This working group h… Andy Lutomirski
- Re: [TLS] Deployment ... Re: This working group h… Martin Rex
- [TLS] multiple clients in one process (was: Re: D… Patrick Pelletier
- Re: [TLS] multiple clients in one process (was: R… Andy Lutomirski
- Re: [TLS] multiple clients in one process (was: R… Daniel Kahn Gillmor
- Re: [TLS] multiple clients in one process (was: R… Nico Williams
- Re: [TLS] multiple clients in one process (was: R… Nikos Mavrogiannopoulos
- Re: [TLS] multiple clients in one process (was: R… Andy Lutomirski