Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

[John Mattsson <[e-mail]>]

Hi Eric,

Eric Rescorla <[e-mail]> wrote:
>Thanks for raising this topic I think it's important. I agree with you on
>the technical situation. As you say, we should be encouraging people to
>move to TLS 1.3, and NULL encryption cipher suites do not provide all the
>guarantees that TLS 1.3 is intended to deliver. [0].
>
>I also agree with you that we probably should not stop people from making
>registrations even of weak ciphersuites, merely because it is not an
>effective way to limit their use and creates interoperability problems.
>However, as you say we should make clear that TLS 1.3 only provides its
>stated security properties when used with strong algorithms. While I think
>it's helpful to add this to the TLS spec, I wonder if this is something
>that should be in the registry in a way stronger than Recommended=N.
>Conceptually, it seems to me that suites fall into three categories:
>
>- The WG has evaluated them and believes they are good (Recommended=Y)
>- The WG has not evaluated them and has no real opinion (Recommended=N)
>- They clearly do not provide some important security properties (???)
>
>We could then put draft-camwinget in the last category (the situation with
>draft-ietf-tls-external-psk-guidance seems a bit more complicated).

I think that sounds like a very good idea. I think the “Recommended" Column is a bit too simple for it's own good. I think it would be worthwhile to make an update to the "Recommended" column.

The current "Recommended" column is easy to misunderstand as recommended to use, while it formally is "recommended to implement". There was also several comments on the list year last year commenting on the "Recommended" column:

Achim Kraus wrote:
"Maybe, one column with recommended (Y/N/<blank>), is not enough."
"I'm still worrying about the "recommended" and the (mis-)interpretation
of that."
"Therefore my proposal to add the Y-period."

Hannes Tschofenig wrote:
"my problem is that the IANA registry only says “not recommended” but it does not say for what environments these ciphersuites are not recommended. Worse, it also wants to indicate whether the specification has gone through the IETF process."

David Benjamin wrote:
"It sounds like the registry may be confusing, so perhaps we, independent of
the existing criteria for Y vs N, need to do a better job of presenting the
information."

I especially like Hannes comment on environment, this is similar to what RFC 8221 and RFC 8247 does IoT. What is recommended to support for IoT, Web, DTLS/SCTP, and DTLS-SRTP, etc. can differ.

Cheers,
John

From: Eric Rescorla <[e-mail]>
Date: Thursday, 11 February 2021 at 18:31
To: John Mattsson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

John,

Thanks for raising this topic I think it's important. I agree with you on the technical situation. As you say, we should be encouraging people to move to TLS 1.3, and NULL encryption cipher suites do not provide all the guarantees that TLS 1.3 is intended to deliver. [0].

I also agree with you that we probably should not stop people from making registrations even of weak ciphersuites, merely because it is not an effective way to limit their use and creates interoperability problems. However, as you say we should make clear that TLS 1.3 only provides its stated security properties when used with strong algorithms. While I think it's helpful to add this to the TLS spec, I wonder if this is something that should be in the registry in a way stronger than Recommended=N. Conceptually, it seems to me that suites fall into three categories:

- The WG has evaluated them and believes they are good (Recommended=Y)
- The WG has not evaluated them and has no real opinion (Recommended=N)
- They clearly do not provide some important security properties (???)

We could then put draft-camwinget in the last category (the situation with draft-ietf-tls-external-psk-guidance seems a bit more complicated).

As far as the contents of draft-camwinget, I concur that it would be better if rewritten in the form you propose, but as its an individual draft -- and I am not in favor of it being taken on as a WG item -- I'm not sure how much it matters. I tend to think it would be better to have something from the WG (e.g., the registry change I propose above) that made the WG's view clear.

-Ekr

[0] You correctly raise the point that without encryption, TLS 1.3 does not deliver protection of endpoint identities. I would also note that it does not provide unlinkability for resumption, even if each ticket is used only once. Moreover, it's not clear to me the extent to which the analyses of TLS 1.3 relied on the fact that the cipher suites provide encryption. While it seems likely that TLS with NULL encryption provides the expected properties (i.e., data origin authentication without confidentiality), I'm not sure we have analysis to that effect.

On Thu, Feb 11, 2021 at 2:03 AM John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>> wrote:
 Salz, Rich wrote:
>Can you explain why TLS 1.2 isn't good enough for your needs?

I think it's bad to force industries requiring visibility to use TLS 1.2 unless it is for a limited time. TLS 1.2 is obsolete. I think the TLS WG should not spend any more time on TLS 1.2.

I personally do not object to the registrations as such. I object to the draft stating that sacrificing confidentiality has latency, cost, power, processing, and code size benefits. There seems to be consensus in the TLS WG that this is most often not the case. The discussions with the authors seem to lead nowhere. I think the draft needs to remove everything regarding benefits. In fact, I think the draft could be very short:

"There are use cases requiring visibility. This memo defines cipher suites without confidentiality for such use cases. This breaks the TLS 1.3 security property "Protection of endpoint identities" and is NOT RECOMMENDED."

That said, I think NULL encryption is a VERY BAD solution to the visibility problem. If visibility is needed, draft-rhrd-tls-tls13-visibility is clearly better.

The TLS WG might also need to discuss when the Appendix E security properties applies. Both draft-camwinget-tls-ts13-macciphersuites and draft-ietf-tls-external-psk-guidance breaks some of the security properties. Maybe this is ok as long as it is NOT RECOMMENDED?

Cheers,
John

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls