Hi Eric, Thanks for your response.
1. There is already no requirement that you have an explicit nonce. RFC5246 merely requires that you specify the length of the explicit nonce, but that length can be 0, as it is in the ChaCha/Poly drafts. So, rather than build an extension it would be better to just define a new cipher suite if you think this is important. [Jay]: The extension idea was mainly for the already defined ciphers in RFC 6655 (for AES_CCM usage in TLS) & RFC 5288 (for AES_GCM usage in TLS). Both these RFCs state that an explicit nonce of 8 bytes MUST be carried in each record. So, in these cases to avoid the overhead, the options as I understand are defining a new extension or a new cipher suite (which suggests the new explicit nonce generation mechanism and makes the record iv length as 0). This new extension is more like a framework for negotiating the type of explicit nonce generation mechanisms. If a particular way of generating the explicit nonce is found to be exploitable in future, a new mechanism can be defined and negotiated through the extension. Defining a new cipher for each new mechanism of explicit nonce generation may increase the number of ciphers that the client has to carry in it’s client hello by a good amount (considering, it needs to carry old ciphers also for backward compatibility with servers not supporting new ciphers). 2. TLS 1.3 already omits the explicit nonce entirely. [Jay]: My primary goal is for DTLS 1.2 which is used with CoAP in various IoT Scenarios. Usage of DTLS 1.2 with CoAP has already started in many products I believe and DTLS 1.3 may take some time and will not be immediately adapted by products already released. Requesting your suggestions in the above context. Thanks Again. Best Regards, Jay *************************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! *************************************************************************************** From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: 24 October 2015 01:35 To: tls@ietf.org; draft-jay-tls-omit-aead-explicit-nonce-extens...@tools.ietf.org Subject: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension I took a quick look at this draft and IMO it is unnecessary, for two reasons: 1. There is already no requirement that you have an explicit nonce. RFC5246 merely requires that you specify the length of the explicit nonce, but that length can be 0, as it is in the ChaCha/Poly drafts. So, rather than build an extension it would be better to just define a new cipher suite if you think this is important. 2. TLS 1.3 already omits the explicit nonce entirely. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
