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

Hubert Kario <hkario@redhat.com> Thu, 02 June 2016 10:40 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 CF96512D132 for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 03:40:00 -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 K7Wrh8QFzB6D for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 03:39:59 -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 5E79412D0BE for <tls@ietf.org>; Thu, 2 Jun 2016 03:39:59 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 152B0C00DDE7; Thu, 2 Jun 2016 10:39:59 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u52Advb9030862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2016 06:39:58 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 02 Jun 2016 12:39:57 +0200
Message-ID: <6238043.DCePXUsCVt@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: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com>
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2003030.C26EvmxeT8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 02 Jun 2016 10:39:59 +0000 (UTC)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3XOu4LDZTTiYZYEMoxfvjcnfWIQ>
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 10:40:01 -0000

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...

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...

-- 
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