Re: [TLS] ALPN concerns

Yoav Nir <ynir@checkpoint.com> Wed, 06 November 2013 03:50 UTC

Return-Path: <ynir@checkpoint.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 57D1E21E815D for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 19:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Level:
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAS0RymQGcqQ for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 19:50:54 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D39B311E81F7 for <tls@ietf.org>; Tue, 5 Nov 2013 19:50:46 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA63ocvU021673; Wed, 6 Nov 2013 05:50:39 +0200
X-CheckPoint: {5279BB23-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 05:50:38 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: AQHO2nVrisyeONraYE22idIo0fVZhpoXR2KAgAATLYCAABWxgA==
Date: Wed, 6 Nov 2013 03:50:38 +0000
Message-ID: <034ABE49-7A26-4018-80F0-049F2724243B@checkpoint.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com> <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com> <m27gcm1cpy.fsf@localhost.localdomain>
In-Reply-To: <m27gcm1cpy.fsf@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.24.225]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E0CBFFB444117644A31EE8633FE4D746@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 06 Nov 2013 03:50:59 -0000

On Nov 5, 2013, at 6:32 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:

> Martin Thomson <martin.thomson@gmail.com> writes:
> 
>> On 5 November 2013 14:21, Brian Smith <brian@briansmith.org> wrote:
>>> I am
>>> very concerned about the issues that they've run into where many web
>>> servers are failing to handshake when the ClientHello message is
>>> larger than 255 bytes.
>> 
>> I can understand the need to avoid the ceiling in the short term, no
>> question.  But how much headroom is there?
>> 
>> Having some specific numbers would definitely help inform the
>> discussion.  Clearly, including SNI with a maximum-length hostname is
>> going to blow this limit, so the question is where we think the line
>> needs to be drawn.
> 
> To give an idea:
> 
> A TLS 1.2 ClientHello which lists all the authenticated ciphersuites
> currently defined (no anonymous), EC curves and formats, and signature
> algorithms, but no SNI, is 528 bytes.  So you can already be way over
> 255 bytes just with things already defined.
> 
> The TLS 1.2 Safari ClientHello in OS X 10.9 when connecting to
> ssl.apple.com is 180 bytes, and that has SNI but no NPN or similar,
> and a limited number of elliptic curves.
> 
> I think the Safari ClientHello is close to the minimum you would want;
> that is, if your ClientHello is much shorter, you're probably missing
> something more important than ALPN.  I would suggest allowing 30 bytes
> for longer domain names.  So there's maybe 45 bytes to split between
> ALPN, TLS 1.4, AEAD ciphers, new elliptic curves, and any other
> feature that might be implemented in future.

Don't forget 32 bytes for session ID or any number of bytes for session ticket in resumption attempts. Now your 45 bytes are down to 13 or less.  

And as for domain names:
http://www.thelongestdomainnameintheworldandthensomeandthensomemoreandmore.com