Re: [TLS] integrity only ciphersuites

[Kathleen Moriarty <[e-mail]>]

Sent from my mobile device

> On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL <[e-mail]> wrote:
> 
> "Vulnerable-by-design ciphersuites"? Vulnerable to what? 
> 
> 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 agree with Uri here, flexibility to cover these use cases to accommodate the actual security requirements may result in them using something instead of nothing.  It could be defined and not listed as Recommended as well.  This comes down to risk management and options, where the risk can be clearly explained and the lack of recommendation can also be explained.

Best regards,
Kathleen 

> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
>> On Aug 21, 2018, at 07:42, Stephen Farrell <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls