On Aug 21, 2018, at 10:16, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: — Regards, Uri Blumenthal Voice: (781) 981-1638 Secure Resilient Systems and Technologies Fax: (781) 981-7537 MIT Lincoln Laboratory 244 Wood Street, Lexington, MA 02421-9185
Web: http://www.ll.mit.edu/mission/cybersec/cybersec-bios/blumenthal-bio.html > 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.) I disagree, but I see your point. >> 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;-) “Tried” is the right term in this context. ;-) > Assuming the only "forbidden" case means ham > radio. Incorrect. But probably the most respectable case. ;-) > 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. I strongly disagree here. It’s been shown that confidentiality without integrity tends to get broken. It has never been shown that integrity without confidentiality has any issues. >>> 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>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
