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

From: Nimrod Aviram <[email-masked]>
Date: Wed, 2 Mar 2022 19:11:42 +0200

Hi Everyone,

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:
1. RSA key exchange is a MUST NOT.
2. Non-ephemeral finite-field DH is a MUST NOT.
3. Non-ephemeral ECDH is a SHOULD NOT.
4. 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.

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Mar 2022 17:18:56 +0000

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.

RSA key exchange is a MUST NOT.

NIST PQC API is Key Encapsulation – conceptually similar to RSA key exchange.

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 above to address concerns previously raised on the list.

best wishes,

Carrick and Nimrod

---

From: David Benjamin <[email-masked]>
Date: Wed, 2 Mar 2022 13:31:31 -0500

> NIST PQC API is Key Encapsulation – conceptually similar to RSA key

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.

>
>    1. Non-ephemeral finite-field DH is a MUST NOT.
>
>
>
>    1. Non-ephemeral ECDH is a SHOULD NOT.
>
>
>
> OK.
>
>
>
>    1. 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.
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Mar 2022 19:06:12 +0000

Nice editing.

We can argueXXXXX rationally discuss the various choices the draft makes once it’s adopted.

And welcome Carrick and Nimrod as new authors!

---

From: Carrick Bartle <[email-masked]>
Date: Wed, 02 Mar 2022 10:46:13 -0800

> 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-masked]> wrote:
> 
> On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 - MITLL <[email-masked] <mailto:[email-masked]>> 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 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.
>  
> 
> 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.
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>