How are these devices authenticating?
On Mon, Aug 20, 2018 at 4:14 PM Nancy Cam-Winget (ncamwing) <ncamwing= 40cisco....@dmarc.ietf.org> wrote: > Hi Eric, > > Thanks for the prompt feedback! Please see further comments/questions > below: > > > > *From: *Eric Rescorla <e...@rtfm.com> > *Date: *Monday, August 20, 2018 at 13:58 > *To: *"ncamw...@cisco.com" <ncamw...@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....@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 > 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
