Hi Stephen, (I do appreciate the feedback, so I also hope the chairs don't mind this discussion continuing)
From my perspective I was thinking that a library could offer these ciphersuites as a compile-time option. As this is targeted towards IoT devices not using HTTP this would be a completely different build environment than the "run of the mill" web communications use case. So when building a particular IoT device these ciphersuites could be compiled in, and then potentially used if it is decided they are necessary. That's what is being done with TLS 1.2 with at least one Industrial Protocol. That is, a handful of authentication only suites (as well as confidentiality suites) are defined, and then when the device is configured the user must make a choice about which cipher suites to use. So the device vendor has to first make a decision that it even makes sense to offer these ciphersuites in their product, and then the user would have to configure the product to either use these ciphersuites or not, ideally having both decision driven by a thorough threat model. I am sensitive to the tool-bending as you describe 😊 My hope is that these options would be clear enough that relevant IoT device vendors get the TLS benefits while not adding undue risk to the more well-known HTTP use case (as the ciphersuites would not even be present for a build supporting this). Thanks, --Jack -----Original Message----- From: Stephen Farrell <stephen.farr...@cs.tcd.ie> Sent: Monday, March 4, 2019 5:53 PM To: Jack Visoky <jmvis...@ra.rockwell.com>; John Mattsson <john.matts...@ericsson.com> Cc: tls@ietf.org Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC 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;-) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
