Re: [TLS] Deprecating Obsolete Key Exchange Methods in TLS

> 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 <davidben@chromium.org> wrote:
> 
> On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu <mailto:uri@ll.mit.edu>> 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
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>