Review of draft-ietf-tls-hybrid-design-05 Good document, some comments:
- "post-quantum cryptography" Have there been an IETF discussion on which term to use? The recently released CNSA 2.0 use the term quantum-resistant (QR) which is probably a better term as post-quantum cryptography will be deployed far before any CRQCs are built. I have not seen any NIST discussion, but I would not be surprised at all if they changed to “quantum-resistant” to align with CNSA 2.0. https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF - I suggest the following change the below definition so that it also covers secp256r1+x25519, secp256r1+secp384r1, and Kyber+NTRU etc. OLD: "means the use of two (or more) key exchange algorithms based on different cryptographic assumptions" NEW: "means the use of two (or more) key exchange algorithms" - "advent of a quantum computer" Quantum computers are already here. Probably better to talk about CRQCs instead of quantum computers in the whole document. - The four initial hybrids seems like the right choices. Might consider Kyber1024 as CNSA 2.0 has chosen that, but on the other hand compliance with CNSA 2.0 means using Kyber1024 without secp384r1. - This document uses the FIPS 202 varient (and not the "90s" varient); I suggest rewriting this so that it does not sound like kyber512 and kyber768 are FIPS. - “For kyber512 and kyber768, this document refers to the same named parameter sets defined in the Round 3”. Should we call this non-standardized versions kyber512 and kyber768? Maybe better to call them kyber512-round3 and kyber768-round3 and something like that. On the other hand NIST might change the name of the standardized versions so there might not be a collision. - Does using IND-CCA2 with reuse of key shares give better performance than using IND-CPA without reusing key shares? Is there any real-world measurements on that? My understanding is that the FO transform is not free. - The IANA registry needs to values for “DTLS-OK” and “Recommended”. - My understanding is that US government will forbid use of hybrid key exchange with the argument that is increases complexity and therefore the risk of vulnerabilities related to implementations bugs. Would be good to mention and discuss this even if you do not agree. Cheers, John From: TLS <[email protected]> on behalf of [email protected] <[email protected]> Date: Sunday, 28 August 2022 at 22:27 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Hybrid key exchange in TLS 1.3 Authors : Douglas Stebila Scott Fluhrer Shay Gueron Filename : draft-ietf-tls-hybrid-design-05.txt Pages : 22 Date : 2022-08-28 Abstract: Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list [email protected] or on the GitHub repository which contains the draft: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-c404f4af2592f2f4&q=1&e=76a29e70-29ac-4f94-87c4-6e6779634ddb&u=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-hybrid-design-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
