Re: [TLS] integrity only ciphersuites

Hi Eric,
Thanks for the prompt feedback!  Please see further comments/questions below:

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday, August 20, 2018 at 13:58
To: "ncamwing@cisco.com" <ncamwing@cisco.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] integrity only ciphersuites

On Mon, Aug 20, 2018 at 1:48 PM, Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org<mailto:ncamwing=40cisco.com@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.
[NCW] We are working diligently in several IoT based consortiums to begin to define security around those protocols as many today do not afford any protection at all.  At minimum, we want to ensure there is mutual authentication and authorization as well as message integrity.  As we cite in the draft, many “things” perform repetitive tasks that want to communicate motion, speed or other machine control functions that are not deemed to be private.
I can see your point/belief that it is much easier to include confidentiality, but some chipsets today especially at those levels (and cost) are not constructed with those provisions today, though they do have HMAC capabilities.

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).
[NCW] So, it is not just about code size, but overall hardware availability and cost….

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