Re: [TLS] integrity only ciphersuites

["Fries, Steffen" <[e-mail]>]

Hi,

Just to add on this, there are different standards in power system automation, which utilize and profile TLS to avoid defining an own security protocol and rely on existing security protocols. This is done for instance in IEC 62351, which requires mutual authentication based on certificates and allows integrity only cipher suites. Within a utility network it may be necessary to monitor the information that is used for control and/or measurement of switchgear or similar entities. Confidentiality it not the first priority here and if the communication crosses the internet (from a substation to a control center), additional measures are used. The same requirement for passive monitoring exists in railway systems for interlocking communication. The intention here is also to be able to monitor the signaling without the need to terminate a security protocol.

If there would be support for integrity ciphers in TLS 1.3 it would enable the straight forward switch from TLS 1.2 also in these environments by keeping existing monitoring options.

Best regards
Steffen Fries


From: TLS <[e-mail]> On Behalf Of Andreas Walz
Sent: Dienstag, 21. August 2018 15:37
To: [e-mail]
Cc: ncamwing=[e-mail]
Subject: Re: [TLS] integrity only ciphersuites

+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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls

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