> NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange. > > > Yes, but this has no bearing on why it's deprecated.
+1. The PQ KEMs aren't relevant here. > On Mar 2, 2022, at 10:31 AM, David Benjamin <[email protected]> wrote: > > On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 - MITLL > <[email protected] <mailto:[email protected]>> wrote: > Following the discussions around draft-bartle-tls-deprecate-ffdh and > draft-aviram-tls-deprecate-obsolete-kex, and after consulting the chairs, we > have merged the two drafts into draft-aviram-tls-deprecate-obsolete-kex > <https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/>. > > > > The merged draft prescribes the following: > > RSA key exchange is a MUST NOT. > NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange. > > > Yes, but this has no bearing on why it's deprecated. > > The question is how you use the KEM, and as well as the properties of the KEM > in question. In TLS 1.3, and in TLS 1.2 (EC)DHE key exchanges, the KEM > recipient generates an ephemeral, per-connection key. This gives us forward > secrecy properties, which this WG has treated as important. In TLS 1.2 RSA > key exchange, the recipient uses a static RSA key. In principle, one could > also use an RSA-based KEM with ephemeral keys, but RSA key generation is so > expensive that this is implausible. Regardless, "RSA key exchange" in the > context of TLS is specifically the TLS 1.2 RSA construction, which doesn't do > this. > > Additionally, the particular KEM-like construction used in TLS RSA key > exchange is flawed, per the Bleichenbacher attack. While we have a > mitigation, it is just a workaround for what is ultimately a flawed > construction. That mitigation has also had a series of implementation issues, > per the documents cited by the draft. > > > Non-ephemeral finite-field DH is a MUST NOT. > > > Overkill, and unnecessary. Should be SHOULD NOT. > > > > Non-ephemeral ECDH is a SHOULD NOT. > > > OK. > > > > Ephemeral finite-field DH (DHE) is a MAY, only when fully ephemeral, and only > using a well-known group of size at least 2048 bits. > > > Overkill, though requiring sufficiently large group size is fine. > > > > > > We added greater justification for point 3 > <https://www.ietf.org/archive/id/draft-aviram-tls-deprecate-obsolete-kex-01.html#name-security-considerations-2> > above to address concerns previously raised on the list. > > > > We'd love to hear your thoughts. > > > > best wishes, > > Carrick and Nimrod > > _______________________________________________ > TLS mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
