Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC

From: John Mattsson <[email-masked]>
Date: Sun, 3 Mar 2019 12:50:38 +0000

Hi Jack,

>I’d expect that there are cases where authenticated encryption would be just as performant, but I’m sure there are cases where just SHA-256 HMAC is more performant.

This is what I would expect for the current cipher suites with GCM and CCM.  Newer AEAD algorithms such as AEGIS (in the CEASAR final portfolio) would probably have lower latency in all cases except when there is hardware acceleration for SHA but not AES.

> Should we put added emphasis on the idea that this is only to be used if confidentiality is not a concern?

That would be appreciated, I guess the main reason to use these cipher suites would be deployments that want visibility for various reasons.

(The tag length for SHA-384 is probably meant to be 48 bytes. Is there any reason to have such HUGE tags?)

Cheers,
John

From: Jack Visoky <[email-masked]>
Date: Thursday, 28 February 2019 at 19:20
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Hi John,

Messages in this category of communications range in size from a couple of bytes to around a hundred or so (I suppose there could be even larger messages but that would be pretty uncommon).  Platforms range quite a bit, but I would say some flavor of ARM is pretty common, with either no OS or some variant of realtime OS.  As I mentioned before there’s also a non-trivial amount of products with some sort of hardware cryptographic acceleration.  Given the large number of platforms and communication conditions I’d expect that there are cases where authenticated encryption would be just as performant, but I’m sure there are cases where just SHA-256 HMAC is more performant.

In the draft we talk about the dual conditions of needing low latency but having a weak need for confidentiality.  The thought was that when both these conditions are present then the authentication only communications makes sense.  I would not support usage of these ciphersuites in a case where latency was important but confidentiality was also needed.  We’ve described a few of these cases within the draft, but I don’t think an exhaustive enumeration of cases would be possible.  What are you thinking?  Should we put added emphasis on the idea that this is only to be used if confidentiality is not a concern?

Thanks,

--Jack

From: John Mattsson <[email-masked]>
Sent: Thursday, February 28, 2019 10:56 AM
To: Jack Visoky <[email-masked]>
Cc: [email-masked]
Subject: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

[Use caution with links & attachments]

Hi,

I dislike having a document (even a internet-draft with non-recommended cipher suites) that kind of implies that confidentially needs to be disabled for low latency. Especially as the suggested cipher suites would increase latency in a lot of cases. Anybody googling (or DuckDuckGoing) “TLS” and “low latency” is now likely to find this document…

Irrespectively of what happens with this document, I suggest either:

  *   Removing any claims about low latency.
  *   Describe exactly which cases the suggested cipher suites provide significantly lower latency.

(The numbers I posted yesterday for aes128gcmv1 was accidently taken from Cortex-A57, the correct numbers for Cortex-A5 are [186.11, 193.94, 203.11], but that is still likely a little bit faster than HMAC-SHA-256).

Cheers,
John

From: John Mattsson <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 27 February 2019 at 13:23
To: Tony Putman <[email-masked]<mailto:[email-masked]>>, Jack Visoky <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] Authentication Only Ciphersuites RFC

Hi,

The document repeats the requirement of low latency several times. It would be interesting to know which platforms/networks/deployments you have in mind. My understanding is that HMAC-SHA-256 only have better latency than AES on a little bit longer messages where the larger block size matters. Short messages are common in many IoT deployments. Looking e.g. at the benchmarks at https://bench.cr.yp.to for "armeabi; Cortex-A5 (417fc051)" on 64 byte messages, SHA-256 alone requires significantly more cycles than AES-GCM for 64 byte messages.

Cycles/byte for 64 bytes
86.14     86.73     93.59     sha256

Cycles/byte for 64+0 encrypt
24.20     24.20     24.34     aes128gcmv1

On more constrained processors such as the Cortex-M0, AES128-CCM also seems to have lower latency than HMAC-SHA-256 on short messages (37677 cycles vs. 48924 cycles) https://github.com/ctz/cifra. On longer messages, HMAC-SHA-256 likely have lower latency (https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/presentations/session7-vincent.pdf). Note that this pdf shows timing for SHA-256, not HMAC-SHA-256.

Increasing the tag size from 8 bytes (CCM_8) or 16 (GCM) to 32 or 64 may also increase the latency as these additional bytes have to be transmitted.

/John

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Tony Putman <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 27 February 2019 at 11:17
To: Jack Visoky <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] Authentication Only Ciphersuites RFC

I take no position on whether this is a good idea or not. Regarding the draft itself, I was expecting to see a clear definition of the integrity check computation in terms of an AEAD-Encrypt computation.. Something along the lines of:
  AEAD-Encrypt-HMAC(write_key, nonce, additional_data, plaintext) =
    plaintext || HMAC(write_key, nonce || additional_data || plaintext)

In particular, AIUI, nonce must be included to prevent replay attacks. Also include N_MIN = N_MAX = 8 bytes.

-- Tony

From: TLS [mailto:[email-masked]] On Behalf Of Jack Visoky
Sent: 26 February 2019 20:54
To: [email-masked]<mailto:[email-masked]>
Subject: [External Mail] [TLS] Authentication Only Ciphersuites RFC

TLS Colleagues,

If you recall we discussed a draft for authentication only ciphersuites over email back in August of 2018.  We've since made some updates to that draft.  We also have gotten IANA assignments to the authentication only ciphersuites for TLS 1.3 and have updated the draft to reflect the new assignments.

To that extent, as the IoT community is looking to adopt these ciphersuites, we would like to solicit review of the draft:

    https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-02

and request that it be published as informational draft given that the IoT forums are looking to adopt its use and the draft can serve as the guide for use and interoperability.

Thanks and Best Regards,

--Jack (and Nancy)

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Jack Visoky <[email-masked]>
Date: Mon, 4 Mar 2019 21:49:01 +0000

Hi John,

OK I will add an update to the draft which further emphasizes that these cipher suites are strictly to be used when confidentiality is not a concern.

Yes good catch on the tag length for SHA-384, I’ll also update that to 48, that appears to be a typo.

Thanks,

--Jack

From: John Mattsson <[email-masked]>
Sent: Sunday, March 3, 2019 7:51 AM
To: Jack Visoky <[email-masked]>
Cc: [email-masked]
Subject: Re: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Hi Jack,

Cheers,
John

From: Jack Visoky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 28 February 2019 at 19:20
To: John Mattsson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC

Hi John,

Thanks,

--Jack

Cc: [email-masked]<mailto:[email-masked]>

Hi,

Cheers,
John

Hi,

Cycles/byte for 64 bytes
86.14     86.73     93.59     sha256

/John

-- Tony

TLS Colleagues,

Thanks and Best Regards,

--Jack (and Nancy)

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 4 Mar 2019 22:52:58 +0000

Jack,

(With the proviso that this isn't and I agree ought not
be a WG item, so the chairs should feel free to tell me to
stop...)

On 04/03/2019 21:49, Jack Visoky wrote:
> OK I will add an update to the draft which further emphasizes that
> these cipher suites are strictly to be used when confidentiality is
> not a concern.
I don't understand how that can be usefully specified for
a TLS implementer. AFAICS there's no credible way a library
with these ciphersuites can refuse to make them available
when there is a need for confidentiality but allow them to
be used when there is apparently no need for confidentiality.
That's just one part of what makes these schemes dangerous.

I honestly don't think that's really fixable tbh. The best
I can think of is to again try convince people who claim
they don't need confidentiality in TLS that they're really
actually better off with it - I don't believe there's any
person or enterprise today who never needs TLS confidentiality
ever, so these schemes also impose a real risk even on those
who promote them. (As well as the rest of us.)

I'm not however expecting to convince you or others who are
promoting this to drop it. (But do feel free:-) I guess all
I can hope is that you've considered the overall costs to
the ecosystem (incl. yourselves) in promoting this stuff.
If you were to document that analysis and those costs then
I think that'd maybe be better than not doing so. But to
add text saying to not use these when confidentiality is
needed seems to me fairly pointless.

S.

PS: for those who really cannot use TLS confidentiality,
e.g. for broadcast applications, my answer is that TLS is
the wrong tool, not that they have gotten their requirements
wrong. (But please don't damage a tool that's good for lots
of other things by bending it out of shape;-)

---

From: Jack Visoky <[email-masked]>
Date: Tue, 5 Mar 2019 22:06:09 +0000

Hi Stephen,

(I do appreciate the feedback, so I also hope the chairs don't mind this discussion continuing)

From my perspective I was thinking that a library could offer these ciphersuites as a compile-time option.  As this is targeted towards IoT devices not using HTTP this would be a completely different build environment than the "run of the mill" web communications use case.  So when building a particular IoT device these ciphersuites could be compiled in, and then potentially used if it is decided they are necessary.  That's what is being done with TLS 1.2 with at least one Industrial Protocol.  That is, a handful of authentication only suites (as well as confidentiality suites) are defined, and then when the device is configured the user must make a choice about which cipher suites to use. 

So the device vendor has to first make a decision that it even makes sense to offer these ciphersuites in their product, and then the user would have to configure the product to either use these ciphersuites or not, ideally having both decision driven by a thorough threat model.

I am sensitive to the tool-bending as you describe 😊  My hope is that these options would be clear enough that relevant IoT device vendors get the TLS benefits while not adding undue risk to the more well-known HTTP use case (as the ciphersuites would not even be present for a build supporting this).

Thanks,

--Jack

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: Monday, March 4, 2019 5:53 PM
To: Jack Visoky <[email-masked]>; John Mattsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] EXTERNAL: Re: Authentication Only Ciphersuites RFC

Jack,

(With the proviso that this isn't and I agree ought not be a WG item, so the chairs should feel free to tell me to
stop...)

> these cipher suites are strictly to be used when confidentiality is 
I don't understand how that can be usefully specified for a TLS implementer. AFAICS there's no credible way a library with these ciphersuites can refuse to make them available when there is a need for confidentiality but allow them to be used when there is apparently no need for confidentiality.
That's just one part of what makes these schemes dangerous.

I honestly don't think that's really fixable tbh. The best I can think of is to again try convince people who claim they don't need confidentiality in TLS that they're really actually better off with it - I don't believe there's any person or enterprise today who never needs TLS confidentiality ever, so these schemes also impose a real risk even on those who promote them. (As well as the rest of us.)

I'm not however expecting to convince you or others who are promoting this to drop it. (But do feel free:-) I guess all I can hope is that you've considered the overall costs to the ecosystem (incl. yourselves) in promoting this stuff.
If you were to document that analysis and those costs then I think that'd maybe be better than not doing so. But to add text saying to not use these when confidentiality is needed seems to me fairly pointless.

S.

PS: for those who really cannot use TLS confidentiality, e.g. for broadcast applications, my answer is that TLS is the wrong tool, not that they have gotten their requirements wrong. (But please don't damage a tool that's good for lots of other things by bending it out of shape;-)