Hiya, On 21/08/18 13:10, Blumenthal, Uri - 0553 - MITLL wrote: > "Vulnerable-by-design ciphersuites"? Vulnerable to what?
Accidental use, at least. If libraries implemented this it could create a need for "!NULL" additions to random configurations for example. (I do accept that vulnerable-by-design might be considered overstated, but I'm looking at his from a "part of TLS" POV and not just at the lower level cryptographic mechanism.) > Suck sites are designed to provide end-point authentication and > traffic integrity. Care to explain/show how these properties would > not hold? > > Besides, it's been explained several times that some use cases do not > require confidentiality, and in some use cases confidentiality is > forbidden. I think I and others addressed those issues. Or tried to, anyway;-) Assuming the only "forbidden" case means ham radio. And it's I think fair to say that a number of times when people have started out thinking they don't need confidentiality, it turned out later that they did. Cheers, S. > > Regards, Uri > > Sent from my iPhone > >> On Aug 21, 2018, at 07:42, Stephen Farrell >> <stephen.farr...@cs.tcd.ie> wrote: >> >> >> >>> 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> >> _______________________________________________ TLS mailing list >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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
