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. Another reason for including them (in particular as the leading values) in the computation of handshake_hash is to have them always located at the same position in the hashed stream. It is needed to make sure that these streams are unique per session (in theory, and maybe in practice, an attacker may play games changing the boundary of nonces by changing surrounding bytes in the stream). If this augmenting of handshake_hash is not adopted then there should be a note cautioning against excluding the nonces from the transmitted messages. If possible, it would be good to move them to a fixed position (from the start of the input to the handshake_hash). Hugo On Thu, Dec 17, 2015 at 10:13 AM, John Foley <fol...@cisco.com> wrote: > On 12/16/2015 04:28 PM, Dave Garrett wrote: > >> On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: >> >>> Thanks for answering my questions. Have you considered adding KAT >>> values for the key derivation steps? This would be helpful to >>> implementors. RFC5869 already has KAT values for HKDF-Extract and >>> HKDF-Expand. But the TLS 1.3 spec has added HKDF-Expland-Label. >>> Additionally, It would be useful to show intermediate KAT values for >>> xSS, xES, mSS, and mES. >>> >> I suggest filing an issue or submitting a PR with a starting point set of >> changes and discussing it with ekr. >> >> > I've submitted https://github.com/tlswg/tls13-spec/issues/378. If you > give me a few days, I'll update this issue with KAT values per revision > 10. Since it sounds like there are changes forthcoming in this section of > the draft, I'll hold off on the PR until later. Hopefully someone else will > volunteer to verify my KAT values. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls