Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension

[Eric Rescorla <[e-mail]>]

On Thu, Oct 29, 2015 at 3:04 PM, Jayaraghavendran k <
[e-mail]> 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:[e-mail] <[e-mail]>] *On
> Behalf Of *Eric Rescorla
> *Sent:* 24 October 2015 01:35
> *To:* [e-mail];
> [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>