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 <john.matts...@ericsson.com> Sent: Sunday, March 3, 2019 7:51 AM To: Jack Visoky <jmvis...@ra.rockwell.com> Cc: tls@ietf.org Subject: Re: EXTERNAL: Re: [TLS] Authentication Only Ciphersuites RFC 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 <jmvis...@ra.rockwell.com<mailto:jmvis...@ra.rockwell.com>> Date: Thursday, 28 February 2019 at 19:20 To: John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Cc: "TLS@ietf.org<mailto:TLS@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> 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 <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Sent: Thursday, February 28, 2019 10:56 AM To: Jack Visoky <jmvis...@ra.rockwell.com<mailto:jmvis...@ra.rockwell.com>> Cc: tls@ietf.org<mailto:tls@ietf.org> 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 <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Date: Wednesday, 27 February 2019 at 13:23 To: Tony Putman <tony.put...@dyson.com<mailto:tony.put...@dyson.com>>, Jack Visoky <jmvis...@ra.rockwell.com<mailto:jmvis...@ra.rockwell.com>> Cc: "TLS@ietf.org<mailto:TLS@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> 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 <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of Tony Putman <tony.put...@dyson.com<mailto:tony.put...@dyson.com>> Date: Wednesday, 27 February 2019 at 11:17 To: Jack Visoky <jmvis...@ra.rockwell.com<mailto:jmvis...@ra.rockwell.com>> Cc: "TLS@ietf.org<mailto:TLS@ietf.org>" <tls@ietf.org<mailto:tls@ietf.org>> 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:tls-boun...@ietf.org] On Behalf Of Jack Visoky Sent: 26 February 2019 20:54 To: tls@ietf.org<mailto:tls@ietf.org> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
