I asked you if you have any specific devices for which this is an issue. Do you? How did you determine that it was an issue? Do you have A/B testing results on power consumption and/or performance of a null cipher suite versus encryption?
On Tue, Aug 21, 2018 at 11:20 AM, Jack Visoky <jmvis...@ra.rockwell.com> wrote: > 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:mel...@fugue.com] > *Sent:* Tuesday, August 21, 2018 10:58 AM > *To:* Jack Visoky <jmvis...@ra.rockwell.com> > *Cc:* Andreas Walz <andreas.w...@hs-offenburg.de>; tls@ietf.org; ncamwing= > 40cisco....@dmarc.ietf.org > *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 <jmvis...@ra.rockwell.com> > 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:tls-boun...@ietf.org] *On Behalf Of *Andreas Walz > *Sent:* Tuesday, August 21, 2018 9:37 AM > *To:* tls@ietf.org > *Cc:* ncamwing=40cisco....@dmarc.ietf.org > *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 <kathleen.moriarty.i...@gmail.com> 08/21/18 3:20 PM > >>> > > > Sent from my mobile device > > > On Aug 21, 2018, at 8:10 AM, Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> 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 <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 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
