Re: [TLS] Downgrade protection, fallbacks, and server time

Hubert Kario <hkario@redhat.com> Thu, 02 June 2016 15:20 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4D312D51A for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.348
X-Spam-Level:
X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6JK6eQznmSJa for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 08:20:48 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDDE312D1E4 for <tls@ietf.org>; Thu, 2 Jun 2016 08:20:48 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 324A9D56EF; Thu, 2 Jun 2016 15:20:48 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52FKkVm031186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 11:20:47 -0400
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Date: Thu, 02 Jun 2016 17:20:35 +0200
Message-ID: <2454213.pazTbBCOtZ@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.4.10-200.fc22.x86_64; KDE/4.14.17; x86_64; ; )
In-Reply-To: <CAF8qwaCx-AyconwmB+mXMtNFYxhRrt7Kkqw+x5xZUgajXw1ZkQ@mail.gmail.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <6238043.DCePXUsCVt@pintsize.usersys.redhat.com> <CAF8qwaCx-AyconwmB+mXMtNFYxhRrt7Kkqw+x5xZUgajXw1ZkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6211702.YXWo4A68NB"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 02 Jun 2016 15:20:48 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HgPWGu4d8OztZKBcvTdeEqe4iec>
Cc: tls@ietf.org
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 02 Jun 2016 15:20:50 -0000

On Thursday 02 June 2016 14:49:52 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario <hkario@redhat.com>; wrote:
> > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> > > In case folks hoped we could bump the ClientHello version without
> > > those dreaded browser fallbacks, I have bad news. :-( 1.3
> > > intolerance
> > > very much exists. (Maybe we should just give up on
> > > ClientHello.version and use an extension? Extensions have rusted
> > > less.)
> > > 
> > > I picked a large list of top sites and tried connecting to them.
> > > Just
> > > under 2% of them could handle a TLS 1.2 ClientHello, but not the
> > > same
> > > ClientHello with the version switched to 1.3 (no other changes, so
> > > I
> > > haven't tested a real 1.3 ClientHello). They're not unknown hosts
> > > either. I expect if you probe any top site list, you'll very
> > > quickly
> > > find some.
> > 
> > there are also servers which choke on large extensions (say 4096 bit
> > DH client key share with 384 bit ECDH key share), so avoiding the
> > bump in version number won't solve all the problems either...
> 
> TLS 1.3 doesn't require clients offer a KeyShare for all groups in the
> first ClientHello. It costs a HelloRetryRequest and another
> round-trip, but I think that's fine. Clients can limit FFDHE in the
> initial ClientHello to servers they've spoken to before or something.
> For unknown servers, if you only predict a couple of EC groups, it
> shouldn't blow it up too badly, but of course we'll just have to see.

isn't one of the main selling points of TLSv1.3 the 1RTT? and if 1RTT 
doesn't work, you still have to do a fallback dance, to a modified 
TLSv1.3 but you still do

given that TLSv1.2 intolerance is not completely eradicated yet, there 
will always be some servers that do not support any kind of extensions 
or changes to client hello's that worked before (see the 256-512byte 
Client Hello problems caused by cipher suite additions)
 
> (Or clients can just not bother with FFDHE to begin with. I don't see
> the point and am not very interested in implementing it at all.)

quantum computing, and while you may not agree, NIST has a different 
opinion on the matter and that's enough of a reason for many people

> > Speaking of version number, does the text say that a server _MUST_
> > accept any version higher than the one that is specified in the RFC,
> > but reply with 0x03,0x04 in case it doesn't support any future
> > version of the protocol? It would be nice to have some kind of
> > stick for the broken implementations...
> 
> I'm not sure I follow. The specification certainly spells out how
> version negotiation is supposed to work. That hasn't stopped servers
> from getting it wrong. Fundamentally this is the sort of thing where
> bugs don't get noticed until we make a new TLS version, and we don't
> do that often enough to keep rust from gathering.

yes, but I don't see it spelling out anywhere that a server MUST accept 
higher numbers, it just describes how the mechanism works up to this 
point, not how it will continue to work

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic