On Sun, Sep 20, 2015 at 6: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? > As I said, a clearer separation between the input keying material used to make traffic keys and that used to make keys which are then input into HKDF. > 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? > I'm going to defer this to Hugo and Hoeteck. > 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. > Why? Note that the next thing we are going to do is use this keys to generate keys which are generally <= 256-bits. It's also worth noting that previous versions of TLS behaved this way as well. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
