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

From: John Mattsson <[email-masked]>
Date: Thu, 11 Feb 2021 10:03:17 +0000

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Feb 2021 09:30:16 -0800

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=
[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Jack Visoky <[email-masked]>
Date: Thu, 11 Feb 2021 19:13:32 +0000

Hi John, Eric,

Thanks for the input. We will certainly make some changes to the draft regarding the inspection case. However, I can’t support removing the performance/latency information completely, as I have heard from those who have this very concern. That said, we will edit the language to make it clear that this is not true in all cases.

Regarding the category “They clearly do not provide some important security properties (???)”, we are happy to add some information into the draft if this is the right (or one of the right) places to do this. I can try to come up with some language on my own, or if the WG has a suggestion we can use that.

Thanks,

--Jack

From: TLS <[email-masked]> On Behalf Of Eric Rescorla
Sent: Thursday, February 11, 2021 12:30 PM
To: John Mattsson <john.mattsson=[email-masked]>
Cc: [email-masked]
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:

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=[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
John

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/tls__;!!JhrIYaSK6lFZ!9sn_TxTOvX9rS3Ow8i2mVqh13RYYXFx8cIAdJNZZHkt-coksvmDv-V62rNDMgRv8Ra6M$>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Feb 2021 11:51:01 -0800

On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky <[email-masked]>
wrote:

> Hi John, Eric,
>
>
>
> Thanks for the input. We will certainly make some changes to the draft
> regarding the inspection case. However, I can’t support removing the
> performance/latency information completely, as I have heard from those who
> have this very concern. That said, we will edit the language to make it
> clear that this is not true in all cases.
>

Well, the draft just claims that there are latency concerns, but doesn't
present details. If you want to make this case, it would be helpful to
present performance numbers that show that these ciphersuites are
substantially faster than the alternative algorithms (in particular
ChaCha20/Poly1305) which is quite fast on many low end platforms.

-Ekr

---

From: Jack Visoky <[email-masked]>
Date: Thu, 11 Feb 2021 23:08:44 +0000

Hi Eric,

I don’t have numbers offhand but I will say that many platforms I have experience with have some sort of HW support, and might include things like DMA. In these cases ChaCha20-Poly1305 is way behind in terms of performance (which is expected as I believe it was mainly targeted to software-only implementations).

I’ll anticipate that someone might ask if GCM is not better that SHA-256 with hardware support, and of course I will have to say it depends on the platform. For some cases it will be, and others it will not. Here is a link to some performance numbers which show SHA-256 is faster than GCM https://www.ti.com/lit/an/swra667/swra667.pdf?ts=1613069390182. In other cases GCM may not be supported on a platform but SHA256 is, of course that’s kind of a strawman but it could occur.

Note I am not endorsing this platform or affiliated with it in any way, just want to give an example. And it really is just an example, sorry to repeat again but I just want to drive home the point that YMMV on things like this.

Thanks,

--Jack

From: Eric Rescorla <[email-masked]>
Sent: Thursday, February 11, 2021 2:51 PM
To: Jack Visoky <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>; [email-masked]
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:
Hi John, Eric,

Well, the draft just claims that there are latency concerns, but doesn't present details. If you want to make this case, it would be helpful to present performance numbers that show that these ciphersuites are substantially faster than the alternative algorithms (in particular ChaCha20/Poly1305) which is quite fast on many low end platforms.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 11 Feb 2021 15:11:54 -0800

On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky <[email-masked]>
wrote:

> Hi Eric,
>
>
>
> I don’t have numbers offhand but I will say that many platforms I have
> experience with have some sort of HW support, and might include things like
> DMA. In these cases ChaCha20-Poly1305 is way behind in terms of performance
> (which is expected as I believe it was mainly targeted to software-only
> implementations).
>
>
>
> I’ll anticipate that someone might ask if GCM is not better that SHA-256
> with hardware support, and of course I will have to say it depends on the
> platform. For some cases it will be, and others it will not. Here is a link
> to some performance numbers which show SHA-256 is faster than GCM
> https://www.ti.com/lit/an/swra667/swra667.pdf?ts=1613069390182. In other
> cases GCM may not be supported on a platform but SHA256 is, of course
> that’s kind of a strawman but it could occur.
>

I doubt it covers the whole difference, but I'd note that SHA-256 is not
the right comparison point, because what you need here is HMAC, which
requires nested SHA invocations. This is especially relevant if you have to
go back and forth to the hardware each time.

-Ekr

Note I am not endorsing this platform or affiliated with it in any way,
> just want to give an example. And it really is just an example, sorry to
> repeat again but I just want to drive home the point that YMMV on things
> like this.
>
>
>
> Thanks,
>
>
>
> --Jack
>
>
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Thursday, February 11, 2021 2:51 PM
> *To:* Jack Visoky <[email-masked]>
> *Cc:* John Mattsson <john.mattsson=[email-masked]>;
> [email-masked]
> *Subject:* Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only
> Cipher Suites
>
>
>
>
>
>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 11 Feb 2021 23:17:44 +0000

+1 to Eric.

Re. GCM – one problem it has is catastrophic failure if nonce is mis-/re-used. Which is why I’d rather see AES-GCM-SIV.

--

Regards,

Uri

There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

From: TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Thursday, February 11, 2021 at 18:13
To: Jack Visoky <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky <[email-masked]> wrote:

Hi Eric,

I doubt it covers the whole difference, but I'd note that SHA-256 is not the right comparison point, because what you need here is HMAC, which requires nested SHA invocations. This is especially relevant if you have to go back and forth to the hardware each time.

-Ekr

Thanks,

--Jack

 

On Thu, Feb 11, 2021 at 11:13 AM Jack Visoky <[email-masked]> wrote:

Hi John, Eric,

-Ekr

---

From: Jack Visoky <[email-masked]>
Date: Fri, 12 Feb 2021 01:30:30 +0000

Yes agreed, and also when you put this into a product there’s usually a whole bunch more considerations than just the raw numbers of how fast the hardware can execute a given crypto primitive. However I wanted to find an example that was public information since companies are often loath to share details of their hardware designs. Despite the imperfect example hopefully the point was not lost that it’s not uncommon for SHA-256 HMAC to run faster than AES-GCM.

Thanks,

--Jack

Sent: Thursday, February 11, 2021 6:12 PM

On Thu, Feb 11, 2021 at 3:08 PM Jack Visoky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

I’ll anticipate that someone might ask if GCM is not better that SHA-256 with hardware support, and of course I will have to say it depends on the platform. For some cases it will be, and others it will not. Here is a link to some performance numbers which show SHA-256 is faster than GCM https://www.ti.com/lit/an/swra667/swra667.pdf?ts=1613069390182<https://urldefense.com/v3/__https:/www.ti.com/lit/an/swra667/swra667.pdf?ts=1613069390182__;!!JhrIYaSK6lFZ!-6S_R_nnK8VCShKHEDM4SzTQUP6OhRI_3xs9gT162qITF1bi4gMu5gPOGAsjoGT_zMvL$>. In other cases GCM may not be supported on a platform but SHA256 is, of course that’s kind of a strawman but it could occur.

-Ekr

Thanks,

--Jack

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 11, 2021 2:51 PM
To: Jack Visoky <[email-masked]<mailto:[email-masked]>>
Cc: John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

-Ekr

---

From: John Mattsson <[email-masked]>
Date: Thu, 18 Feb 2021 16:53:34 +0000

Hi Eric,

>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 <[email-masked]>
Date: Thursday, 11 February 2021 at 18:31
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

John,

-Ekr

Cheers,
John