On Sun, Sep 20, 2015 at 9:56 PM, Brian Smith <br...@briansmith.org> wrote:
> On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> https://github.com/tlswg/tls13-spec/pull/248 >> >> Aside from some analytic advantages >> > > What are the analytic advantages? > The advantages are: a cleaner separation of keys derived from ES and SS, a simpler proof argument (via the explicit functional separation of extract and expand steps), and the ability to represent the whole key derivation scheme via the extract/expand steps or via full HKDF calls, whichever is more convenient (the latter gives significant flexibility to an implementation depending on its API to the full HKDF function or to its extract and expand components). > Also, a question that applied even to the older design: I remember the an > HKDF paper and the HKDF paper stating that before it is safe to use a value > as an HKDF salt, it must be authenticated. But, in both the old and new > designs it seems like an authenticated value is being used as the salt in > the HKDF-Extract(mSS, mES) operation. What does this mean for the security > analysis? > It seems that when you say "an authenticated value" you actually mean "an unauthenticated value". If I got it wrong let me know. Assuming this interpretation of your question let me point out that the value mSS is server-authenticated by virtues of g^s being authenticated (via a server's signature or a server-configuration) hence it complies with the RFC (and paper). > One of the notes in the new design draws some attention to the strange > fact that we compress the output of the ECDHE operation to the length of a > digest function that is independent of the length of the ECDH keys used. > For example, if we used P-256 in the ECDHE operation for a AES-128-GCM > cipher suite, we'd compress the output to 256 bits using HKDF-Extract with > SHA-256. But, if we used P-521 in the ECDHE operation for the same cipher > suite, we'd still compress the output to 256 bits using HKDF-Extract with > SHA-256. That seems wrong. I would guess it makes more sense to choose the > HKDF digest algorithm based on the size of the ECDHE key. Note that in the > NSA Suite B Profile for TLS, they fixed this by requiring a more rigid > relationship between the ECDHE key size and the cipher suite than what TLS > requires. See [1]. I think it's worth considering whether the current > (older and newer) design makes is better or worse than a design like the > NSA Suite B Profile in this respect. > Ekr answered this. If you still feel something is wrong let us know. Hugo > > [1] https://tools.ietf.org/html/rfc6460#section-3.1. > > Cheers, > Brian > -- > https://briansmith.org/ > > > _______________________________________________ > 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
