Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

[Jack Visoky <[e-mail]>]

Hi Ted,

My apologies for being opaque.  There are many different device/applications/installations so I am sorry if I am mixing ideas here.  Generally the NULL ciphers have the benefit around allowing higher performance for devices that are lower horsepower.  Code space can certainly be a concern, but I think for industrial applications it’s more around throughput of high speed I/O, combined with the use cases that derive little benefit from the confidentiality of this data.  “Horsepower” is of course a vague term in of itself, so here I’m talking about things that would impact packet processing; this includes processor speed, available high speed RAM, presence of/lack of crypto acceleration (not in many Industrial Ethernet devices but growing).  I wouldn’t put the executable code size as high on the list of concerns as these items, although there are certainly devices that are limited in this.  This horsepower limitation is directly related to the fact that these devices are expected to function for many years.

I’m happy to clarify any of these points further if needed.

Thanks and Best Regards,

--Jack

From: Ted Lemon [mailto:[e-mail]]
Sent: Tuesday, August 21, 2018 10:58 AM
To: Jack Visoky <[e-mail]>
Cc: Andreas Walz <[e-mail]>; [e-mail]; ncamwing=[e-mail]
Subject: Re: [TLS] EXTERNAL: Re: integrity only ciphersuites

Thanks, Jack, but could you respond to the specific questions that we asked you?   Earlier you were saying that your motivation for using NULL ciphers was that you had specific hardware that couldn't implement encryption due to lack of horsepower or memory.   Now you seem to be saying something completely different.   It's going to be difficult for us to understand your requirements if you talk about different things in each message.

On Tue, Aug 21, 2018 at 10:27 AM, Jack Visoky <[e-mail]<mailto:[e-mail]>> wrote:
(I’m responding  a few different points made here)

In general, although this seems like a niche application, there are actually millions of Industrial Ethernet nodes, with the numbers trending upward.  As mentioned, many of these are relying on older protocols designed without security in mind.  Our industry has had a debate around using TLS vs. creating something specific.  Many of us prefer to rely on the security benefits of TLS.  To another point, although I work for Rockwell Automation, here I am working in my capacity within ODVA, a standards group for Industrial Communications that has several large vendors as members.  We have adopted TLS to protect our industrial Ethernet traffic, and one of the selling points of TLS 1.2 was the ability to use NULL encryption.

NULL encryption is not really as much about code size but capability of the devices.  The TLS handshake of course contains some “heavyweight” operations, although handshakes are pretty infrequent as these connections are often quite long-lived.  Once the handshake is over, the I/O data that is transferred is often quite sensitive to latency, and although the encryption overhead might not seem like much when the HMAC is considered, it is still a case where in many applications every bit counts.  Regarding older hardware that exists for many years, some hardware does have cryptographic acceleration although may not have AES-GCM, rather SHA-256 HMAC.  Alternatively, the hardware might not have any crypto acceleration as it was designed without TLS in mind.  At the same time we’d like to secure this traffic via a firmware upgrade.  Despite this, if using encryption drops performance enough users will simply not use it, which is a net worse outcome.  Users will likely not upgrade hardware for many years due to a variety of industry factors.

Kathleen’s comment about defining NULL encryption but being clear about the risks resonates with me.  I’m certainly not suggesting that NULL encryption is needed in all cases, but there are times (as discussed here and in the RFC draft) where it could be quite beneficial.

Thanks and Best Regards,

--Jack

From: TLS [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Andreas Walz
Sent: Tuesday, August 21, 2018 9:37 AM
To: [e-mail]<mailto:[e-mail]>
Cc: ncamwing=[e-mail]<mailto:[e-mail]>
Subject: EXTERNAL: Re: [TLS] integrity only ciphersuites


[Use caution with links & attachments]

+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

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