[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
From: Eric Rescorla <ekr () rtfm ! com>
Date: 2015-10-29 6:10:37
Message-ID: CABcZeBPbt+V3JHiED_AjzNT5cgawX3i+f2AQAfeew54cZvvGVQ () mail ! gmail ! com
[Download RAW message or body]
On Thu, Oct 29, 2015 at 3:04 PM, Jayaraghavendran k <
jayaraghavendran.k@huawei.com> 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:tls-bounces@ietf.org <tls-bounces@ietf.org>] *On
> Behalf Of *Eric Rescorla
> *Sent:* 24 October 2015 01:35
> *To:* tls@ietf.org;
> draft-jay-tls-omit-aead-explicit-nonce-extension@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
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct \
29, 2015 at 3:04 PM, Jayaraghavendran k <span dir="ltr"><<a \
href="mailto:jayaraghavendran.k@huawei.com" \
target="_blank">jayaraghavendran.k@huawei.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi \
Eric,<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks \
for your response. <u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p> </span><p class="MsoNormal">1. There is already no requirement \
that you have an explicit nonce. RFC5246<u></u><u></u></p><span class=""> <p \
class="MsoNormal">merely requires that you specify the length of the explicit nonce, \
but that<u></u><u></u></p> <p class="MsoNormal">length can be 0, as it is in the \
ChaCha/Poly drafts. So, rather than build<u></u><u></u></p> <p class="MsoNormal">an \
extension it would be better to just define a new cipher suite if you \
think<u></u><u></u></p> <p class="MsoNormal">this is important.<u></u><u></u></p>
</span><p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">[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).</span></p></div></div></blockquote><div><br></div><div>Yes, but we're already \
defining new cipher suites with that</div><div>(e.g., ChaCha). So given the small \
number of AEAD cipher</div><div>suites, defining a new cipher suite seems \
better.</div><div><br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
lang="EN-US" link="blue" vlink="purple"><div><span class=""> <p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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).</span></p></span></div></div></blockquote><div><br></div><div>Defining a \
whole pile of explicit nonce generation mechanisms seems</div><div>bad. If we \
actually run into a situation where the hardcoded nonce</div><div>generation \
technique is broken, we can define an extension \
then</div><div><br></div><div><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
lang="EN-US" link="blue" vlink="purple"><div><span class=""> <p \
class="MsoNormal"><u></u> <u></u></p> </span><p class="MsoNormal">2. TLS 1.3 already \
omits the explicit nonce entirely.<span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">[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.</span></p></div></div></blockquote><div><br></div><div>Seems like this \
gives them an incentive to move to \
1.3.</div><div><br></div><div>-Ekr</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><span \
class=""> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Requesting \
your suggestions in the above context.<u></u><u></u></span></p> <p \
class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks \
Again.<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Best \
Regards,<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Jay<u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#1f \
497d">***************************************************************************************<br>
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!<br>
***************************************************************************************</span><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span \
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> \
<u></u></span></p> <div style="border:none;border-top:solid #b5c4df \
1.0pt;padding:3.0pt 0cm 0cm 0cm"> <p class="MsoNormal"><b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span \
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> TLS \
[<a href="mailto:tls-bounces@ietf.org" \
target="_blank">mailto:tls-bounces@ietf.org</a>] <b>On Behalf Of </b>Eric \
Rescorla<br> <b>Sent:</b> 24 October 2015 01:35<br>
<b>To:</b> <a href="mailto:tls@ietf.org" target="_blank">tls@ietf.org</a>; <a \
href="mailto:draft-jay-tls-omit-aead-explicit-nonce-extension@tools.ietf.org" \
target="_blank"> draft-jay-tls-omit-aead-explicit-nonce-extension@tools.ietf.org</a><br>
<b>Subject:</b> [TLS] \
draft-jay-tls-omit-aead-explicit-nonce-extension<u></u><u></u></span></p> </div>
<p class="MsoNormal"><u></u> <u></u></p>
</span><div>
<p class="MsoNormal">I took a quick look at this draft and IMO it is unnecessary, for \
two reasons:<u></u><u></u></p><div><div class="h5"> <div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1. There is already no requirement that you have an explicit \
nonce. RFC5246<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">merely requires that you specify the length of the explicit \
nonce, but that<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">length can be 0, as it is in the ChaCha/Poly drafts. So, rather \
than build<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">an extension it would be better to just define a new cipher \
suite if you think<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">this is important.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">2. TLS 1.3 already omits the explicit nonce \
entirely.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Ekr<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" rel="noreferrer" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><br> \
<br></blockquote></div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic