Re: [TLS] Authentication Only Ciphersuites RFC

[John Mattsson <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, 27 February 2019 at 13:23
To: Tony Putman <[e-mail]>, Jack Visoky <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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 <[e-mail]> on behalf of Tony Putman <[e-mail]>
Date: Wednesday, 27 February 2019 at 11:17
To: Jack Visoky <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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:[e-mail]] On Behalf Of Jack Visoky
Sent: 26 February 2019 20:54
To: [e-mail]
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.