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
>