Jack, (With the proviso that this isn't and I agree ought not be a WG item, so the chairs should feel free to tell me to stop...)
On 04/03/2019 21:49, Jack Visoky wrote: > OK I will add an update to the draft which further emphasizes that > these cipher suites are strictly to be used when confidentiality is > not a concern. I don't understand how that can be usefully specified for a TLS implementer. AFAICS there's no credible way a library with these ciphersuites can refuse to make them available when there is a need for confidentiality but allow them to be used when there is apparently no need for confidentiality. That's just one part of what makes these schemes dangerous. I honestly don't think that's really fixable tbh. The best I can think of is to again try convince people who claim they don't need confidentiality in TLS that they're really actually better off with it - I don't believe there's any person or enterprise today who never needs TLS confidentiality ever, so these schemes also impose a real risk even on those who promote them. (As well as the rest of us.) I'm not however expecting to convince you or others who are promoting this to drop it. (But do feel free:-) I guess all I can hope is that you've considered the overall costs to the ecosystem (incl. yourselves) in promoting this stuff. If you were to document that analysis and those costs then I think that'd maybe be better than not doing so. But to add text saying to not use these when confidentiality is needed seems to me fairly pointless. S. PS: for those who really cannot use TLS confidentiality, e.g. for broadcast applications, my answer is that TLS is the wrong tool, not that they have gotten their requirements wrong. (But please don't damage a tool that's good for lots of other things by bending it out of shape;-)
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
