Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

Dave Garrett <> Mon, 21 September 2015 04:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 974B11A879E for <>; Sun, 20 Sep 2015 21:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NbgV2Qiij3BL for <>; Sun, 20 Sep 2015 21:57:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D24D11A879F for <>; Sun, 20 Sep 2015 21:57:50 -0700 (PDT)
Received: by qgev79 with SMTP id v79so80886055qge.0 for <>; Sun, 20 Sep 2015 21:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=51n3SNdi7mAB3RkDvYoKULp3h6yq4xBv45yfJdAERp8=; b=kl4YHKQwhaEypGVaFjoaaLeg9nDj1EjM3VujlYhIBT9cIQHgWkaQk/lOS5pzJdBctq XUfAuENUNMeMsddiFcu5ysqq14IwZyY6t94VHLxsEUzNqLQxgLnzBrIHS6hLDO3UFTez WuU7udZxZA3kAtfD7qb4S/OWn3+f1wu9PA9dSVCtN3+dlXwxBDxt6LQxr4bCzvwwp5k1 l+DtPdYJLY6rzlsjJQwrzSuemh7xBNzKD2R3/rANcNhjERXmI7l5zEkilAnZa/0zMETI /T/mATlX8ScQxHMugkV/S9EkPPsMqT2YEVb7+0hX4WinpZRQ2qua/sh9mhoua5dW9Ix7 +HZQ==
X-Received: by with SMTP id 75mr20089243qgj.13.1442811470104; Sun, 20 Sep 2015 21:57:50 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id f1sm9163436qhe.42.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 20 Sep 2015 21:57:49 -0700 (PDT)
From: Dave Garrett <>
Date: Mon, 21 Sep 2015 00:57:48 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Sep 2015 04:57:52 -0000

On Monday, September 21, 2015 12:20:21 am Dave Garrett wrote:
> The max _total_ payload size of all extensions is 2^16-1. There are also mandatory extensions for TLS 1.3, as well as others that will customarily be used, thus the max available space is less.
> No, I don't think the limit can be raised. The general ClientHello format has to stay frozen for interoperability with other versions, and unless I'm misreading things, the size of the length of a vector can't change. A separate message seems like what would be needed to have a larger first-flight payload. (and any new messages would need to be signaled via an extension, though it could have a 0-length payload)

To amend my previous email:

Another option might be to implement things as an encrypted-only TLS extension. This would restrict it to 0-RTT mode only, meaning clients would need the server's semi-static config in order to use it. (retrieved from a previous connection or possibly through an out-of-bound method, yet to be specified) This would, however, put it in the EncryptedExtensions message which currently has a similar 2^16-1 limit, but this is new so it could be changed. Again, though, that might not be the best idea.


In case you're confused as to where the limit I'm referring to comes from:

The notation is somewhat atypical. The value/range in angle brackets is the length, in bytes, of the vector, rather than the length in total number of elements.

The ClientHello.extensions vector max size is 2^16-1:

Each Extension.extension_data vector max size is also 2^16-1:

And... actually, looking at this, I think that could be considered wrong. The max individual extension payload size would be 2^16-5, to account for overhead. Less, of course, taking into account other extensions in the same hello.