Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance

Hubert Kario <hkario@redhat.com> Wed, 27 July 2016 10:11 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 7BDC412DE58 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 03:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level:
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, 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 5TOD3w4ZPrp5 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 03:11:05 -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 5764112DE57 for <tls@ietf.org>; Wed, 27 Jul 2016 03:11:05 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 093DF61E46; Wed, 27 Jul 2016 10:11:05 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6RAB3in015344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2016 06:11:04 -0400
From: Hubert Kario <hkario@redhat.com>
To: Brian Smith <brian@briansmith.org>
Date: Wed, 27 Jul 2016 12:10:58 +0200
Message-ID: <1629967.plfWTD6YRj@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.4-301.fc24.x86_64; KDE/5.24.0; x86_64; ; )
In-Reply-To: <CAFewVt64sj2-oFQDL=PKDcfJifaLc=yNwyaz_Dy2j57e2qAKqQ@mail.gmail.com>
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com> <CAFewVt64sj2-oFQDL=PKDcfJifaLc=yNwyaz_Dy2j57e2qAKqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1707201.2DXUWuQ52S"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 27 Jul 2016 10:11:05 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/34ur1fezVHdY7tthyKcU-e_EVOo>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Client Hello size intolerance Was: Re: Thoughts on Version Intolerance
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: Wed, 27 Jul 2016 10:11:06 -0000

On Tuesday, 26 July 2016 16:27:32 CEST Brian Smith wrote:
> Hubert Kario <hkario@redhat.com>; wrote:
> > TLS 1.3                                  170       3.8742
> > TLS 1.4                                  183       4.1705
> > 
> > size e/1356                              10        0.2279
> > size e/1356 c/1356                       5         0.1139
> > size e/1356 c/1357                       5         0.1139
> > size e/2046                              1         0.0228
> > size e/2046 c/1979                       1         0.0228
> > size e/2049                              4         0.0912
> > size e/2049 c/1153                       1         0.0228
> > size e/2049 c/2049                       2         0.0456
> > size e/2049 c/2050                       1         0.0228
> > size e/2053                              1         0.0228
> > size e/2053 c/555                        1         0.0228
> 
> When we consider the most reasonable (initial) ClientHello sizes, it
> seems that the ClientHello version number intolerance is a much more
> significant problem than size intolerance, if I'm understanding your
> numbers correctly.

you've missed one more number:

> > Of those, 45 (1.03%) could not be connected to (did not receive a Server 
> > Hello/.../Server Hello Done reply) with the "Very Compatible" client hello

so while TLS1.3 intolerance it is a bigger problem, it's a bigger problem by a 
factor of two or three (depending what sizes you consider problematic), not by 
an order of magnitude

And given that the "best"[1] key share for post quantum crypto now is 1824 
bytes in size, going above 2048 byte for client hello's on first connect is 
not unreasonable. That is *if* rlwe with those parameters turns out to be good 
enough and we won't need something even larger.

 1 - https://www.imperialviolet.org/2015/12/24/rlwe.html
-- 
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