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

On Wed, Mar 2, 2022 at 12:19 PM Blumenthal, Uri - 0553 - MITLL <
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:
>
>    1. 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.

>
>    1. Non-ephemeral finite-field DH is a MUST NOT.
>
>
>
> Overkill, and unnecessary. Should be SHOULD 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.
>
>
>
> 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
> https://www.ietf.org/mailman/listinfo/tls
>