On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <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 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
