On 20/08/18 21:48, Nancy Cam-Winget (ncamwing) wrote: > All, A couple IoT consortiums are trying to embrace the improvements > made to TLS 1.3 and as they define their new security constructs > would like to adopt the latest protocols, in this case TLS 1.3. To > that extent, they have a strong need for mutual authentication, but > integrity only (no confidentiality) requirements. > > In following the new IANA rules, we have posted the draft > https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-00 > to document request for registrations of HMAC based cipher selections > with TLS 1.3…..and are soliciting feedback from the WG on the draft > and its path forward.
As ekr pointed out, with the new registration rules, there's nothing to stop someone defining any old set of crypto stuff and getting non-recommended codepoints. That said, I don't consider that defining such vulnerable-by-design ciphersuites is a good plan. - It imposes costs on the non-niche users of TLS - once these things are defined then developers and those who deploy/configure applications using TLS need to check that they're not using these undesirable ciphersuites, so costs are being displaced from niche uses to the vast majority of implementations and deployments, which seems to me to be a bad idea. And we know that people will sometimes get those checks wrong leading to unexpected transmission of plaintext over the Internet. - Similarly, just defining such ciphersuites seems likely to lead to less well tested and infrequently used code paths, which is undesirable. (Assuming someone pays some developer to add these to some library, which generally does seem to happen.) - RFC7525 [1] is clear on this topic (after debate in the UTA WG) - "Implementations MUST NOT negotiate the cipher suites with NULL encryption" and I see nothing new to convince me that that ought change for TLS1.3. - Code footprint arguments aren't that convincing to me - to get interop for the few devices where AES being present or absent could make a real difference, you'd need an awful lot more profiling of TLS or DTLS. I don't see evidence of that so the interop/footprint arguments seem pretty weak. I'd also bet that any useful "tiny footprint" profile of that kind would end up targeting loads of use-cases where confidentiality is absolutely required. - (In addition to the good points made by Geoffrey Keating [2]) cleartext payloads would also assist in device fingerprinting, making it easier to exploit vulnerabilities at scale. - IIUC there is also a desire to encrypt firmware updates so that patches can be distributed more quickly than attackers can reverse-engineer attacks. [4] I'm not entirely sure if that's really likely to happen, but if it were, then devices would need to be able to use recommended ciphersuites in any case. - TLS/AX.25 doesn't seem that good a plan in any case - according to [3], which seems reasonable to me, using clear-signed GPG is quicker and better meets the oddball regulations. Attempting to deal with those regulations by weakening TLS seems like a very bad plan, as you'd fail in any case to achieve interop with normal TLS applications like the web. (And the advertising is as illegal as the crypto apparently, though I do like that aspect:-) - WRT unix sockets, I'm not clear that there's a sufficiently important performance improvement in real deployments to justify introducing weakened ciphersuites - presumably mail servers are going to use standard TLS libraries that (I hope!) won't be offering NULL encryption, so I'd be surprised if the right engineering decision was to prioritise CPU to that extent, given the risks associated with having weak ciphersuites present in widely used implementations. IOW, it seems more sensible to me for mail servers to just stick to using RECOMMENDED ciphersuites. And given that you could use SASL with Postfix/LMTP [5] I'm not sure why you'd want a weirdo-version of TLS1.3 anyway but maybe there's some reason I don't get. - I think this WG has had to spend waaaay too much time dealing with the "inspection of data" debate in various forms, but we did get an answer (no consensus) in the end for that. Niche use cases seem extremely unlikely to me to justify revisiting that painful topic. So all in all, I just don't see a need for these weak-by-design ciphersuites to even be defined. I'd encourage folks who think they're needed to instead think about how using RECOMMENDED ciphersuites might make their implementations more widely applicable and safer. Seems like a much more productive approach to me anyway. Regards, S. [1] https://tools.ietf.org/html/rfc7525 [2] https://mailarchive.ietf.org/arch/msg/tls/uI8xVgp7gTuJgwUyY-UgZfmUkRo [3] https://tools.ietf.org/html/draft-ietf-suit-architecture-01#section-3.3 [4] https://www.tapr.org/pdf/DCC2010-AX.25-AuthenticationEffects-KE5LKY.pdf [5] http://www.postfix.org/SASL_README.html#client_sasl
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
