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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7A5341A872E for <>; Sun, 20 Sep 2015 21:20:26 -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 ClOoie-5i1cS for <>; Sun, 20 Sep 2015 21:20:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A53A1A872B for <>; Sun, 20 Sep 2015 21:20:24 -0700 (PDT)
Received: by qgez77 with SMTP id z77so81106053qge.1 for <>; Sun, 20 Sep 2015 21:20:23 -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=GbS5UP/yEUrjoRUCZmiJCHdaB7trLCBovq71elg89+4=; b=VAouaVfA/o7yUswiXDLzo2tbKutiBU/8tymrdHkyQPaytGZXvmiQr3yKYvdyjmB6sS +cXhDtdIKvY+hRqoORBKB2M+r8e0Iohz2Y7kXvVLv7GK7ulfzzjKy6yRnV+TmuPtLn/4 UPymZsYt8N3Srplb1aI52A378U+ThMWvPLuRYSYXYSEe73/IjZqziPbFlyX1hON62HD2 SnaOYd8RCJaQf8daGRHcsF/zHSK5TYTS35i3zOxToiwsz+1jbr/ImRsUmJNfHS2ENPKm qjvaP8SJTnX3txErVryzaBd7aqzxG/P8M+mHThuACbKkkoRe0WGUQ80WvdJNvkYO/dZE AfqA==
X-Received: by with SMTP id n51mr19923246qge.75.1442809223634; Sun, 20 Sep 2015 21:20:23 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 8sm9252889qgi.1.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 20 Sep 2015 21:20:23 -0700 (PDT)
From: Dave Garrett <>
To: William Whyte <>
Date: Mon, 21 Sep 2015 00:20:21 -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:20:26 -0000

On Sunday, September 20, 2015 10:59:58 pm William Whyte wrote:
> Hi all,
> We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as
> suggested by DKG in Prague. All comments welcome.
> There's an interesting issue here: McEliece keys, which should be
> permissible, are larger in size (about 2^20 bytes) than the maximum
> permissible extension size (2^16-1). In order to support McEliece keys it

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.

> might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3.

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)

Also, 16MiB sounds kinda crazy for a first flight, especially one that you can't guarantee the server will understand. Something more like a 21-bit limit sounds less nuts, but that's still 2MiB. I don't think it's a good idea to allow this to be effectively unbounded, so a reasonable (arbitrary) limit should probably be imposed.

> Is there a strong reason for keeping the maximum size at 2^24-1, other than
> saving one byte on all the relevant length fields?

Typo? Did you mean "keeping the maximum size at 2^16-1"?

A strong reason is it not being possible to change due to the need for TLS 1.3 clients to be able to connect to TLS 1.2 servers that won't understand a format change. Even if it were technically possible, I wouldn't expect all implementations to safely handle it.

> Cheers,
> William
> ---------- Forwarded message ----------
> From: <>
> Date: Sun, Sep 20, 2015 at 10:32 PM
> Subject: New Version Notification for draft-whyte-qsh-tls13-01.txt
> To: Zhenfei Zhang <>, William Whyte <
>>, "John M. Schanck" <
> A new version of I-D, draft-whyte-qsh-tls13-01.txt
> has been successfully submitted by William Whyte and posted to the
> IETF repository.
> Name:           draft-whyte-qsh-tls13
> Revision:       01
> Title:          Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer
> Security (TLS) version 1.3
> Document date:  2015-09-20
> Group:          Individual Submission
> Pages:          18
> URL:
> Status:
> Htmlized:
> Diff: 
> Abstract:
>    This document describes the Quantum-Safe Hybrid ciphersuite, a new
>    cipher suite providing modular design for quantum-safe cryptography
>    to be adopted in the handshake for the Transport Layer Security (TLS)
>    protocol version 1.3.  In particular, it specifies the use of the
>    NTRUEncrypt encryption scheme in a TLS handshake.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat