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= 40ericsson....@dmarc.ietf.org> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
