> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
>
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <h...@ee.technion.ac.il
> <mailto:h...@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 ||
> server random ||
> 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? :)
>
> -Ekr
While I haven’t been following TLS 1.3 development all that closely, I will
question this request.
TLS is annoying to implement and analyze in part because it hashes more-or-less
arbitrary parts of the handshake messages together, in arbitrary order, at
arbitrary times. Removal of all the explicit hashing of client/server random
in TLS 1.3 makes it clearer what’s going on, and makes implementations simpler.
Some of the crypto operations still feel pretty arbitrary (particularly
Finished), but things seem to be improving overall. In this context, it feels
like adding client random and server random back to the hash is a regression.
From an analysis point of view, the client and server random are parseable from
Hash(handshake messages) because they are concatenated with framing
information. But here, they are concatenated without framing information. So
I don’t understand Hugo’s contention that the old scheme leads to trouble if
the nonce changes sizes in a later version, and that the new scheme does not.
It seems to me that the reverse is more likely to be true.
Cheers,
— Mike
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
