[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] Explicit use of client and server random values
From: Benjamin Kaduk <bkaduk () akamai ! com>
Date: 2016-01-05 20:36:34
Message-ID: 568C2952.7010503 () akamai ! com
[Download RAW message or body]
On 12/17/2015 02:11 PM, Eric Rescorla wrote:
>
>
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il
> <mailto:hugo@ee.technion.ac.il>> wrote:
>
> I have mentioned this in private conversations but let me say this
> here: I would prefer that the nonces be explicitly concatenated to
> the handshake hash. That is,
>
> handshake_hash = Hash(
>
> client random ||
>
> serverrandom ||
>
> Hash(handshake_messages) ||
>
> Hash(configuration) || )
>
>
> The reason is that nonces are essential for freshness and session
> uniqueness and I want to see them explicitly included in the
> signed/mac-ed/KDF-ed information. I can envision a future
> variant/mode of the protocol where parties do not transmit nonces
> but have a synchronized state that they advance separately and use
> as nonces (e.g., for key refreshing) - in such case the nonces
> would not be included in the handshake-hash computation.
>
> So while the redundancy of having them twice in the handshake_hash
> calculation may be annoying, this adds robustness to the security
> (and analysis) of the protocol.
>
>
> This change doesn't make implementation or specification significantly
> more difficult.
> Does anyone else object or feel it makes analysis harder? :)
>
I don't object, but since elsewhere in the thread the possibility of
changing the size of or omitting the randoms in the future came up, I
will mention the possibility of adding length/framing information and/or
labels into the hash input as well as the randoms themselves.
-Ben
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/17/2015 02:11 PM, Eric Rescorla wrote:<br>
<blockquote
cite="mid:CABcZeBPjFV+moohtdkcso8Ah=550yvNuT0066EiG2q+Wqxg4Yw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 17, 2015 at 3:02 PM, Hugo
Krawczyk <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hugo@ee.technion.ac.il" \
target="_blank">hugo@ee.technion.ac.il</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div
style="font-family:verdana,sans-serif;font-size:small">I
have mentioned this in private conversations but let
me say this here: I would prefer that the nonces be
explicitly concatenated to the handshake hash. That
is, </div>
<div
style="font-family:verdana,sans-serif;font-size:small"><br>
</div>
<div style="font-size:small">
<pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><font \
face="monospace, monospace">handshake_hash = Hash( </font></pre>
<pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)"><font \
face="monospace, monospace"> <span \
style="font-size:13.3333px">client random </span><span \
style="font-size:13.3333px">||</span></font><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px"><font face="monospace, \
monospace"> server<span style="font-size:13.3333px"> \
random ||</span></font></pre><pre \
style="font-size:13.3333px;margin-top:0px;margin-bottom:0px"><font face="monospace, \
monospace"> Hash(handshake_messages) ||</font></pre><font \
face="monospace, monospace"> Hash(configuration) || \
)</font><font face="verdana, sans-serif"> </font></pre>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">The reason
is that nonces are essential for freshness and
session uniqueness and I want to see them explicitly
included in the signed/mac-ed/KDF-ed information. I
can envision a future variant/mode of the protocol
where parties do not transmit nonces but have a
synchronized state that they advance separately and
use as nonces (e.g., for key refreshing) - in such
case the nonces would not be included in the
handshake-hash computation.</div>
<div style="font-family:verdana,sans-serif"><br>
</div>
<div style="font-family:verdana,sans-serif">So while
the redundancy of having them twice in the
handshake_hash calculation may be annoying, this
adds robustness to the security (and analysis) of
the protocol.</div>
</div>
</div>
</blockquote>
<div> </div>
<div>This change doesn't make implementation or
specification significantly more difficult.</div>
<div>Does anyone else object or feel it makes analysis
harder? :)</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
I don't object, but since elsewhere in the thread the possibility of
changing the size of or omitting the randoms in the future came up,
I will mention the possibility of adding length/framing information
and/or labels into the hash input as well as the randoms themselves.<br>
<br>
-Ben<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic