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

David Benjamin <davidben@chromium.org> Wed, 27 July 2016 12:48 UTC

Return-Path: <davidben@google.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 4660C12D753 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 05:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 eF3tpJzLZTxN for <tls@ietfa.amsl.com>; Wed, 27 Jul 2016 05:48:40 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B940E12D74F for <tls@ietf.org>; Wed, 27 Jul 2016 05:48:39 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id l69so26562937lfg.1 for <tls@ietf.org>; Wed, 27 Jul 2016 05:48:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0DR9UJKYv578o/hZlZWELlVaXZ1l/v0HQXMlc6iVVlo=; b=Yv4Rc2GVBtsXUUy1dwxHrbosv6L42LKyK2eYDK5kh4igppVjoYhZhUk+LlLJ0fAr9m H5b3vZhp4nY4AWTgomhWMgY+zgrBoZ2cMcctFzN0pmpCeJmsswKHV+8oQGeyDug/8DmL P9eC3wDaLJzop1PHdy6mdj2bl+wri1UoR6Ne4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0DR9UJKYv578o/hZlZWELlVaXZ1l/v0HQXMlc6iVVlo=; b=hD3SJFI9P0bB0WJnkq6JMtPLH17F/XYYM6IAtKzByRkwr+AYWiiC+wd0DRR8dJoUdK HVO7ewWv/98ND9Ah+frf1AFlVxGm33gEevrpZ7OgWxzuA+Ah2s0QGn9SPi+xR0/bdovf rqnaPncmbojO/92UhC5Jwwki+ptjrIXCZUUTLCPCYHF7nGmFeZiZP8QIBFnGnNoPwUKZ RxrRIxXzgAr3jdy7FOV2G2x55KN/YijayhBeV+5mBRIpSKtKzrroDTJkbdQiOttrn7+S xSViB39t5u10JJxzV57JiXaZEruQGUUb3ZvYM1K7M4JTCAh7kW6OOyoS4xVsFQ3iaRrK lr8Q==
X-Gm-Message-State: AEkoouty/6jGm8FdWlt/a5KToxn2CvwcrtUu+pyro4Fg0tsBW+L6xPdB/SSRDv0acJLMBDrUzUd0+aZQaDpfW+H/
X-Received: by 10.25.168.212 with SMTP id r203mr12960477lfe.85.1469623717784; Wed, 27 Jul 2016 05:48:37 -0700 (PDT)
MIME-Version: 1.0
References: <20160720173027.9BC3D1A504@ld9781.wdf.sap.corp> <10280200.XEPfMK1A2H@pintsize.usersys.redhat.com> <CAFewVt64sj2-oFQDL=PKDcfJifaLc=yNwyaz_Dy2j57e2qAKqQ@mail.gmail.com> <1629967.plfWTD6YRj@pintsize.usersys.redhat.com>
In-Reply-To: <1629967.plfWTD6YRj@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 27 Jul 2016 12:48:28 +0000
Message-ID: <CAF8qwaBU0SLo5RsxemAnQwn34PuNBd_Omj_EfT-B84O2WXncvg@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>, Brian Smith <brian@briansmith.org>
Content-Type: multipart/alternative; boundary=001a114032a2a742f205389d6f60
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PKD8wBTlv5AAOLZ8D8l9UYdj7dg>
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 12:48:43 -0000

On Wed, Jul 27, 2016 at 6:11 AM Hubert Kario <hkario@redhat.com>; wrote:

> 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


While we will indeed someday need to deal with that problem, it is still a
ways out. Even with no intolerance of any kind, I do not expect any
reasonable client to be willing to waste that much bandwidth on a key share
that the vast majority of servers will not use. (HelloRetryRequest exists,
so there is no need to predict all groups.)

Checking numbers from Chrome, the overwhelming majority of today's ECDHE[*]
servers select P-256, though one can expect X25519 to start coming up.
(Google servers select it today, and I believe OpenSSL 1.1.0 is expected to
as well. Probably others too.) With no prior knowledge, those two groups
seem by far the most reasonable to send in an initial ClientHello. For
reference, our in-progress TLS 1.3 implementation in Chrome does this with
a 517-byte ClientHello, of which 186 bytes are the padding to bring it up
to 5 + 512.

With prior knowledge, of course, many things are possible. Perhaps a client
will remember the group a server used last time (or use the
ServerHello.supported_groups extension) and, if we believe the server
prefers an unpredicted group, even if much much larger, predict that one.
With prior knowledge, endpoint intolerance is less of a concern.

I can imagine various unpleasant options should we need to balance
predicting a widely-used large key share with intolerance, but by then any
plans we make now will no longer be valid anyway.

David

[*] Negotiated FFDHE exists in TLS 1.3 and server-fiat DHE in TLS 1.2, but
this irrelevant as those two are totally different animals anyway. All they
have in common is the last three letters.