Subject: Re: [Uta] WGLC for draft-ietf-uta-rfc7525bis-04

From: Thomas Fossati <[email-masked]>
Date: Mon, 24 Jan 2022 09:42:57 +0000

Hi Nimrod,

Thanks for your comments and apologies for the slow response time.

From: Uta <[email-masked]> on behalf of Nimrod Aviram <[email-masked]>
> Coauthor of draft-bartle-tls-deprecate-ffdhe here (the document is
> undergoing reorganization, and the work-in-progress state can be found
> here).
>
> draft-ietf-uta references the deprecate-ffdhe draft as a future TODO
> item in Section 6.4.  There are a few notable differences between the
> recommendations in the two drafts:
>
> - The draft-ietf-uta lists RSA key exchange as a SHOULD NOT. We've had
> similar discussions in the TLS WG, and I argue that RSA should be a
> MUST NOT. We've had support for this on the TLS WG.
>
> - The wording in Section 4.1 of draft-ietf-uta implies that using
> finite field DHE cipher suites is generally good practice. Most web
> client implementations have dropped support for finite field DHE.
> Further, the Introduction of WIP draft-tls-deprecate-obsolete-kex
> lists problems affecting finite field DHE, especially when exponents
> are reused. These problems are arguably severe enough to make exponent
> reuse a MUST NOT. Section 6.4 has both static finite field DH and
> exponent reuse as a SHOULD NOT.
>
> - On a side note, the list of recommended cipher suites in Section 4.2
> is a subset of the recommended cipher suites in the "Intermediate"
> configuration in Mozilla's Server Side TLS Guide. Could one of the
> authors please explain the rationale for this difference?
>
> Obviously, my recommendations are reflected in the WIP
> draft-tls-deprecate-obsolete-kex:
> (please excuse the brevity)
> - MUST NOT use (non-ephemeral) DH cipher suites.
> - SHOULD NOT use non-ephemeral ECDH.
> - Finite field DHE: MUST NOT reuse exponents, MUST use a well-known
>   group.
> - MUST NOT use RSA key exchange.
>
> I look forward to your responses.
>
> best, and happy holidays,
> Nimrod

Please see https://github.com/yaronf/I-D/pull/290

cheers!
--

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Nimrod Aviram <[email-masked]>
Date: Mon, 24 Jan 2022 14:16:04 +0200

Hi Thomas,

I understand you're going with non-ephemeral finite-field Diffie-Hellman as
a SHOULD NOT?
Could you please elaborate on your reasons for this decision?

thanks,
Nimrod

On Mon, 24 Jan 2022 at 11:43, Thomas Fossati <[email-masked]> wrote:

> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 24 Jan 2022 12:29:51 +0000

Hi Nimrod,

> Nimrod Aviram <[email-masked]> wrote:
>
> I understand you're going with non-ephemeral finite-field
> Diffie-Hellman as a SHOULD NOT?

I would expect that raising the normative bar to MUST NOT should come
in a document with TLS WG consensus -- e.g., draft-bartle/draft-aviram.

In the meantime, what we can do from the UTA/BCP point of view is
sticking a strong warning label on it.

cheers, t
--