Re: [TLS] Advancing draft-ietf-tls-hybrid-design

Douglas Stebila <> Mon, 12 July 2021 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D46C3A00E5 for <>; Mon, 12 Jul 2021 10:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 igCXhFkBKh9s for <>; Mon, 12 Jul 2021 10:56:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0AB253A07A5 for <>; Mon, 12 Jul 2021 10:56:18 -0700 (PDT)
Received: by with SMTP id z12so14536651qtj.3 for <>; Mon, 12 Jul 2021 10:56:18 -0700 (PDT)
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=zAM+doWdTlZfjAseoqALQBJRXzUmHWZnJMmmGxgSru4=; b=ius2hUj3ZYBvR6tDHZu2gc70MxlzVFjE3qMcYqZsNmFWjn5NUWM9sn80w72CIgdha9 9DtIsDH/XxWsFOyjW0djbW282fFLIxnicltxBkFC5fhvTBOmoPXNpeRkjbXadJa9QqLN RDVr56KNhW76gvjInKTQiGbG8koUflNYe0f86Uv+AfmSUdhMjAtZ6i2yar50X1qJx5tX c5CACyUS6t6i/ZBamuBX37+vuqjhxjJCZC5hfKBuOBWFQOFdCd9TQG3JqC8kL11ooeBl hQ3WVe5AqrSrsU/zdd+dgcnKIJx7OZa6mTT6Jto/Q9JDTfDv6xZEFhsgltnvB+d2yMmU W67w==
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=zAM+doWdTlZfjAseoqALQBJRXzUmHWZnJMmmGxgSru4=; b=q7YZMa+whNRi+Ka1yWxOnPQkraneX7STqDQ62pmaJ6ZUnYOlPuBVS4G9JrejXhlzVE Tx9EqCj/F0zHzr2I9KBHUN5w7cnx1gzjfI8pGb0I/0h+Jswgb16RXXobXbWYSoOd8ySO fb44JCULySu4XDss3acxkrX8CHPzhJOyeRaXoduIacPRvgrfKsiKM4ZfEqY62hs1Qhkw DlLjo7Dpldqv7NFEdU+h2tAeQ+s4QeDSfWbr1RMQiuPOzzdNQVXESyZ02iCagh8Neofx 4lj9x5WaSdTYQ9Vm92hSPzo0FZDks2wQqUiIi/pVipDZSpuGJxffIik2ROu1yyYnol5i 8uJg==
X-Gm-Message-State: AOAM531xUqOcOLj1NK3f5mfu9wd+j76Bho9N0oTlF9EBCUKjUd/oP5ah WekwegCLg9DcVfFwXx6JUt4=
X-Google-Smtp-Source: ABdhPJyMgMqskSX0Tcc5cDCdzQqnRMkbUA9Kaw/Eq9MWgLVDXzGoSmpP2wJTK/LnvB2OW0MS5Ad9VA==
X-Received: by 2002:a05:622a:1042:: with SMTP id f2mr71399qte.210.1626112577121; Mon, 12 Jul 2021 10:56:17 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 18sm3388963qkv.118.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 10:56:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Douglas Stebila <>
In-Reply-To: <>
Date: Mon, 12 Jul 2021 13:56:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [TLS] Advancing draft-ietf-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: Mon, 12 Jul 2021 17:56:35 -0000

Thanks Martin.  All makes sense, and I'll incorporate in a revision.  Though at this point changing the word "hybrid" to "composite" would be a rather big rewrite so I'll omit that unless there are very strong objections to the word hybrid.


> On Jul 6, 2021, at 21:53, Martin Thomson <> wrote:
> I just took a look.  I didn't read the (large) appendices, though I appreciate that they have value.
> The draft is largely in good shape.  I have a few minor concerns.
> I don't think that you want to reserve the hybrid_private_use(0x2F00..0x2FFF) range of values.  There were specific reasons for an FFDHE range that I don't think apply if we constrain this design to TLS 1.3 and higher (as we should).  The same applies to the 0x02.. prefix you suggest for the use of hybrid codepoints.
> I find the emphasis on the NIST process a little strong for what is a permanent artifact.  It is OK to note its existence as motivation for the work, but I would avoid over-emphasis.  For example:
> OLD:
>   Moreover, it is possible that even by the end of the NIST Post-
>   Quantum Cryptography Standardization Project, and for a period of
>   time thereafter, conservative users may not have full confidence in
>   some algorithms.
> NEW:
>   Moreover, it is possible that after next-generation algorithms are defined, and for a period of
>   time thereafter, conservative users may not have full confidence in those algorithms.
> and 
> OLD:
>   In the context of the NIST Post-Quantum Cryptography Standardization
>   Project, key exchange algorithms are formulated as key encapsulation
>   mechanisms (KEMs), which consist of three algorithms:
> NEW:
>   This document models key agreement as key encapsulation
>   mechanisms (KEMs), which consist of three algorithms:
> Please avoid "defining" codepoints, even in examples:
> OLD:
>   For example, a future document could specify that hybrid value 0x2000 corresponds to
>   secp256r1+ntruhrss701, and 0x2001 corresponds to x25519+ntruhrss701.
> NEW:
>   For example, a future document could specify that one codepoint corresponds to
>   secp256r1+ntruhrss701, and another corresponds to x25519+ntruhrss701.
> Finally, the use of the word "hybrid" is awkward.  Maybe "composite" is a less-heavily overloaded term that accurately captures the intent; with an antonym of "unitary" or "discrete".
> When you talk about concatenation, it might pay to cite the relevant appendix.  I would also note that the goal is that when the composed elements are not fixed-length, a length prefix might be used to ensure that both secrets contribute all of their entropy without being exposed to a weakness in the other.  (You might say that the composition is injective.)
> Section 4 includes questions to which I think answers can be given now:
> *Larger public keys and/or ciphertexts.* => I think that the answer here has to be "too bad".  Just note that TLS cannot handle a KEM that includes values larger than 2^16 (minus a little bit).
> *Duplication of key shares.* => Your existing text is sufficient to answer this one.
> *Resumption.* => There isn't much existing language on this point, but I don't see it as needing anything special in this draft.  My view is that fresh entropy of any kind is an improvement, but generally we will see better than that because clients and servers will perform a fresh key exchange with an algorithm that they consider sufficient at the time.  That might result in a change in posture relative to the original session, but the result should still be as good as min(original, current), which is always better than just using the PSK.
> *Failures.* => KEM failure is a problem, but I would do nothing more than note the potential and have the handshake fail.  I see that the finalists have low enough error rates that this doesn't seem likely to be an issue in practice.  Clients can always try again if they hit this specific problem.  Ours already retries in a bunch of different failure cases.  Some text on this point in the draft is probably sensible.
> Nits:
> OLD:
>   However, the
>   key_exchange values for each algorithm MUST be generated
>   independently.
> NEW:
>   However, 
>   key_exchange values for different algorithms MUST be generated
>   independently.
> On Wed, Jul 7, 2021, at 11:19, Douglas Stebila wrote:
>> Dear TLS working group,
>> We wanted to see if there is any further feedback on our draft "Hybrid 
>> key exchange in TLS 1.3" 
>> ( and 
>> what steps are required for it to advance further.  We have not 
>> received any new feedback from the working group since we posted our 
>> last non-trivial update in October 2020.
>> The draft as written does not actually specify any post-quantum 
>> algorithms nor give identifiers for specific algorithm combinations, 
>> only the formats for hybrid key exchange messages and key derivation.  
>> We have received a suggestion that the draft be updated to include 
>> identifiers for hybrid key exchange combining elliptic curve groups and 
>> the KEMs currently in Round 3 of the NIST PQC standardization process, 
>> so that implementations can begin testing interoperability using 
>> numbers listed in the draft, rather than relying on ad hoc lists for 
>> such purposes.  Is that something the working group would like to see, 
>> or would you prefer to leave it as it currently stands, without any 
>> specific algorithm identifiers?
>> Douglas, Scott, and Shay
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list