Re: [TLS] ALPN concerns

Martin Thomson <martin.thomson@gmail.com> Wed, 06 November 2013 01:24 UTC

Return-Path: <martin.thomson@gmail.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 485B921E808F for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 17:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 vQvinE8oKUK1 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 17:24:23 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 11AA521E80F3 for <tls@ietf.org>; Tue, 5 Nov 2013 17:24:20 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id q58so4231446wes.17 for <tls@ietf.org>; Tue, 05 Nov 2013 17:24:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qq1N7zW68i+/TC//9FcvbpeKT0ukyCQhpfnDHF1t2Ho=; b=wNdh9/gqtTDfW5UFHbkJHZxvU/lk8bMXOmY0afYYXhUspT7r9M1susxW1C2x7mCpxE Mn+cRxMsYyCfVkEGvZgkMFlJbCAL02B0rKeh8YKrQWjBIS7vzM3PzN0P/0rlXkZn/kR2 5goOTWrqfRIVKtmzmtJ20EiRMJyxvGnTrvtGx+SrvNu5UJpLuViK1IIbbCdAvNMPcbzG 1R+mniJzugJ755+BrnFItbAaAuoII3uFqlzfHDnENUV37cHC/0VmmA5uGeOMnFUKa4q1 KMVxTH0cmGWCoBNEP0PkPtu+oFNuS6Oy0OyxlcmGxhN0pGk+1W1kRZ5MFa6neKoYL+kP C3VQ==
MIME-Version: 1.0
X-Received: by 10.194.240.197 with SMTP id wc5mr354019wjc.23.1383701059900; Tue, 05 Nov 2013 17:24:19 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 17:24:19 -0800 (PST)
In-Reply-To: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
Date: Tue, 05 Nov 2013 17:24:19 -0800
Message-ID: <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
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 01:24:24 -0000

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.

Given information on sizes, there are other options available to us.
Changing to shorter ALPN strings, or even moving to binary identifiers
(which would be unpleasant, but probably manageable) are definitely
still possible.  And those are only the solutions that are constrained
to ALPN, if you are willing to look elsewhere, you might instead
suppress SNI instead for long hostnames.  After all,
http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/
created this problem for themselves.

If we're that close to the limit, then a great many of the advantages
of TLS1.3 are likely to be eliminated.  Most of the 0-RTT modes won't
work.