Re: [TLS] integrity only ciphersuites

["Andreas Walz" <[e-mail]>]

+1

I fully understand the pursuit of minimizing complexity in TLS. However,
banning from TLS all provisions to serve non-internet cases seems
suboptimal to me.

I think there is a whole universe of systems and applications that are
just at the very beginning of being armed with security features: think
of communication systems driving, e.g., industrial automation and
critical infrastructures. These are quite different from the internet
and the web (different threats, security requirements, architectures,
networks, resources, etc.). Still, IMHO it's not a niche at all; it's
just not as visible to most of us.

I strongly believe it is *not* a good idea to hold back all the valuable
experience condensed in TLS and entail the design of customized security
protocols for such systems. TLS is state-of-the-art and its benefits
should be accessible to as many systems as possible. 


Cheers,
Andi Walz 



>>> Kathleen Moriarty <[e-mail]> 08/21/18 3:20
PM >>>


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>> 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

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls