On Thu, Oct 29, 2015 at 3:04 PM, Jayaraghavendran k < [email protected]> wrote:
> 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). > Yes, but we're already defining new cipher suites with that (e.g., ChaCha). So given the small number of AEAD cipher suites, defining a new cipher suite seems better. > 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). > Defining a whole pile of explicit nonce generation mechanisms seems bad. If we actually run into a situation where the hardcoded nonce generation technique is broken, we can define an extension then > > 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. > Seems like this gives them an incentive to move to 1.3. -Ekr 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:[email protected] <[email protected]>] *On > Behalf Of *Eric Rescorla > *Sent:* 24 October 2015 01:35 > *To:* [email protected]; > [email protected] > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
