I tend to think the strongest scenario for integrity-only ciphersuites is in an application where the data being transferred is already encrypted sufficiently. For example, when running IPsec over an IP-HTTPS tunnel, Microsoft used a null cipher on the outer TLS layer. However, as you say, this can be deceptive. DRM-protected media is already encrypted and seems like another application for this, but using TLS means it is not (as) trivial to identify that different flows are retrieving the same resource.
From: TLS <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Monday, August 20, 2018 1:58 PM To: Nancy Cam-Winget (ncamwing) <ncamwing=40cisco....@dmarc.ietf.org> Cc: tls@ietf.org Subject: Re: [TLS] integrity only ciphersuites On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <ncamwing=40cisco....@dmarc.ietf.org<mailto:ncamwing=40cisco....@dmarc.ietf.org>> 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. Nancy, As you say, you don't need WG approval for code point registration as long as you don't want Recommended status. With that said, I don't think this document makes a very strong case for these cipher suites. Essentially you say: 1. We don't need confidentiality 2. Code footprint is important Generally, I'm not very enthusiastic about argument (1). It's often the case that applications superficially need integrity but actually rely on confidentiality in some way (the obvious case is that HTTP Cookies are an authentication mechanism, but because they are a bearer token, you actually need confidentiatilty). It's much easier to just always supply confidentiality than to try to reason about when it is or is not needed. The second argument is that you are trying to keep code size down. It's true that not having AES is cheaper than having AES, but it's possible to have very lightweight AES stacks (see for instance: https://github.com/01org/tinycrypt). So, overall, this doesn't seem very compelling.. -Ekr Warm regards, Nancy (and Jack) _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
