Hi, I think this is a very straightforward way to introduce hybrid keying to TLS 1.3. I think this extension will increase the use of TLS 1.3 in national security systems, which I think is very welcome. This kind of hybrid keying / defense-in depth is exactly what is recommended in the excellent PhD thesis by Martin Ekerå [1], who is also chief cryptographer of the Swedish NCSA.
As long as the extension does not alter the certificate authentication or the ephemeral key exchange, I do not see any way it could lower the security, but I am not against formal analysis. I am satisfied with the Privacy Considerations section and would like to see this draft published as proposed standard. Some comments on draft-ietf-tls-8773bis-02: - - - "There are two motivations for using a certificate with an external PSK." For national security systems, I think it is motivated to always use hybrid keying, combining symmetric keying with post-quantum secure asymmetric keying. The recommendation in [1] is to combine symmetric keying, post-quantum secure asymmetric keying, and classically secure asymmetric keying, as a defense-in depth. See Algorithm 1 and Figure A.1 of [1]. - - - "but it will take many years for TLS 1.3 ciphersuites that use these algorithms to be developed and deployed" X25519MLKEM768 already seem developed and deployed. - - - "Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension." I don't think the MUST NOT follows from that "tls_cert_with_extern_psk" is intended to be used only with initial handshakes. External PSKs can be used with "early_data" in the initial handshake according to RFC 8446. Suggestion: NEW: "tls_cert_with_extern_psk" MUST NOT be sent alongside the "early_data" extension." - - - "However, TLS 1.3 does not permit an external PSK to be used in the same fashion as a resumption PSK, and this extension does not alter those restrictions" I don't know what these restrictions on external PSK are and I could not find them in RFC 8446. - - - "For protection against the future invention of a CRQC, the symmetric key needs to be at least 128 bits It needs to be at least 128 bits to protect against classic computers as well. The sentence is also duplicated in the following paragraph. Suggestion: NEW "For protection against the future attacks, the symmetric key needs to be at least 128 bits" - - - "the advantage of Grover’s algorithm will be smaller." I don't think Grover's will ever have any practical advantage. In addition to cost and parallelization, two additional factors mentioned in footnote 18 of [1] are: "large-scale fault-tolerant quantum computers as currently envisaged are very slow compared to classical computers" "The overheads incurred by the need to employ quantum error correction to achieve fault tolerance are furthermore substantial." - - - - "If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. I think certificate-based server authentication SHALL be used even if the external PSK is known only be the client and the server. - - - "In addition, clients MAY also include psk_ke mode to support a subsequent NewSessionTicket." I think this draft focusing on hybrid keying in high-security systems should forbid psk_ke. - - - Cheers, John [1] Ekerå, "On factoring integers, and computing discrete logarithms and orders, quantumly" http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
