Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

Douglas Stebila <> Thu, 13 February 2020 11:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BC9F1200C3 for <>; Thu, 13 Feb 2020 03:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IEoA0tbfDlhN for <>; Thu, 13 Feb 2020 03:39:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2EB6120043 for <>; Thu, 13 Feb 2020 03:39:50 -0800 (PST)
Received: by with SMTP id c188so5316901qkg.4 for <>; Thu, 13 Feb 2020 03:39:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z2dkq6FgfDFvqYBZvPkhP5tjGl8MKQtxlODb6krYQsA=; b=NW3SVdwkRMAbYlBUdLXePouJhyJvs/KdopjLyOc4IOG1gD6DxN/Ph7asbh86UExyEZ 3K+qLMamFYB0l3OtU9m7+70fG40tCbbEnerg7aSPe3iONocq4Myo9wMRWZwfrltscJBy CGv2aT/6hD7pfXVTAjiU6rjRkOEguR4SkG8CWVtWsp6v6EWEoFWGXmotUdmwpRm3UhCj wcrX+DAhQ6NN3mYsegbSZPMnn7qlMOdfYSlkIFGLD+oKWL7r6LYHE94bippcTz8z9+hZ uN14go+0amxR6D+L6pJR9ZCLybn9lLBVHyYoIsvE9jtmnmD5M12OY2daTdDxz4r6ybCs 3vew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z2dkq6FgfDFvqYBZvPkhP5tjGl8MKQtxlODb6krYQsA=; b=hzSdptSyagbwerWECH1HG3cAq5ou/uQ5SY+G2pBaHbp27RbMctDzIXEKKchHkucTe8 AuOW7UgLiGTz8gnPVjPZeYmsqITO19TssHECOhL/kNOZ6/2g61waJLZCimmauqrio50B dmuTcgn4f/QfaxKD3OAwzu6PB0Fj0g6EQp7b3EmWh02MVOfywJOEareuenfzaluAkZsP zdsBVWt2FbhUvb4cWGySkZatMFd/myYO1m1B3RKZc0sC65kpe4qdyLoY4ixWIO1ha3dv G3EG6/aTXmpmMRXJfYrQUkG760mFq3/zFM55bFQORTlwY8/cmaDCo9QSBeq5bw57KmG+ cEFw==
X-Gm-Message-State: APjAAAWtevh1/3cjMbotMq+sL43ZI0qeKdgcJ2v1iq3yZnsHMYs6o9Xb vUe0eYs/XFT3q+lo65F449HvUS5i
X-Google-Smtp-Source: APXvYqziYnK52rgIi8ApCvSXlTiIYZ6RarLvY7MfRif7v4ah1a/98O+5I6X6jQEkn9U5b7jfwqHwDA==
X-Received: by 2002:ae9:e8d2:: with SMTP id a201mr4890552qkg.47.1581593989941; Thu, 13 Feb 2020 03:39:49 -0800 (PST)
Received: from laptop-picard.coleridge ( []) by with ESMTPSA id l19sm1149447qkl.3.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Feb 2020 03:39:49 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Douglas Stebila <>
In-Reply-To: <>
Date: Thu, 13 Feb 2020 06:39:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design
X-Mailman-Version: 2.1.29
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: Thu, 13 Feb 2020 11:39:52 -0000

Hi Martin,

Thanks for the suggestions.  Indeed, happy to incorporate changes in framing, tone, etc. to better reflect the purpose of the document.

> At a high level, I think that this would be easier if it were more clearly framed as *recommendations*, especially when it comes to the format of key shares and the input secret.  One advantage of the macro-level design is that the format is can be specified on a case-by-case basis.  For instance, variable-length values might be length-prefixed; fixed size values don't need to be.  That might avoid having to directly specify a single format. 
> [...]
> The concatenation approach is definitely my preferred approach, but the inconsistency between the design for key shares and secrets is curious.  This design assumes that shares are length-delimited; secrets are not.  The latter implies that the `ss` needs to be fixed length for a given algorithm (both the PQ and classical parts), but `ct`/`pk` does not.  I can guess at why, but when you can avoid the question, then I think you should.  That is, in favour of more generic recommendations on structure.

There are examples of current PQ candidates that have variable sized ct / pk: SIKE has compressed and uncompressed variants, which are mathematically interoperable and would result in the same shared secret, but trade smaller communication for more computation.

To the best of my knowledge, none of the current PQ candidates have variable sized shared secrets.

We did have some debate internally when preparing the draft about whether shared secrets should have length encoding or not, and in the end decided not, despite the apparent inconsistency in design.