Hi Rich, Sean and all, 1) Traditionally, a HKDF-Extract is used to extract entropy from a DH type shared secret. However, the first HKDF-Extract in the key schedule takes a PSK instead of a DH shared secret.
We don't see security problems with this instance in TLS 1.3. NIST requires the PSK to have efficient amount of entropy (to achieve a security strength required by NIST) when it is externally generated. When it is externally generated, one of NIST's approved random bit generation methods in SP 800-90 series must be used. When the PSK is a resumption key, then its original key exchange and its key derivation function(s) must meet the security strength desired/required for the PSK. NIST plans to allow/approve the function in SP 800-133r2, Section 6.3, item # 3 on pages 22 and 23: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2-draft.pdf 2) Traditionally, HKDF is extract-then-expand. However, in TLS 1.3, we have extract-then-multiple expands. We don't see security problems for this new version of HKDF as specified in TLS 1.3. NIST plans to approve a general method for this approach in SP 800-56C revision 2, section 5.3: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2-draft.pdf NIST plans to handle the issues above that way to avoid repeating the work when one or both of the same HKDF instances or new variant(s) for one or both of them is/are used in different application(s). The other KDFs are already compliant with NIST's existing KDFs. Regards, Quynh. Recommendation for Key-Derivation Methods in Key-Establishment Schemes<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2-draft.pdf> 23 . Draft NIST Special Publication 800-56C 24 . Revision 2 25 Recommendation for Key-Derivation 26 . Methods in Key-Establishment Schemes 27 . 28 . 29 Elaine Barker 30 Lily Chen 31 Computer Security Division 32 . Information Technology Laboratory nvlpubs.nist.gov ________________________________ From: Cfrg <cfrg-boun...@irtf.org> on behalf of Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> Sent: Friday, May 8, 2020 4:21 PM To: tls@ietf.org <tls@ietf.org>; c...@ietf.org <c...@ietf.org> Subject: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3) If you don’t care about FIPS-140, just delete this message, and avoid the temptation to argue how bad it is. NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-Establishment Schemes) is currently a draft in review. The document is at https://csrc.nist.gov/publications/detail/sp/800-56c/rev-2/draft Email comments can be sent to 800-56c_comme...@nist.gov with a deadline of May 15. That is not a lot of time. The NIST crypto group is currently unlikely to include HKDF, which means that TLS 1.3 would not be part of FIPS. The CMVP folks at NIST understand this, and agree that this would be bad; they are looking at adding it, perhaps via an Implementation Guidance update. If you have a view of HKDF (and perhaps TLS 1.3), I strongly encourage you to comment at the above address. Please do not comment here. I know that many members of industry and academia have been involved with TLS 1.3, and performed security analysis of it. If you are one of those people, *please* send email and ask the NIST Crypto Team to reconsider. Thank you. /r$ _______________________________________________ Cfrg mailing list c...@irtf.org https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg&data=02%7C01%7Cquynh.dang%40nist.gov%7C6ba71a06d50f41e6582508d7f38d7d80%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637245661358887556&sdata=5DEzorMNakxeh%2Bkb4wYJ00QxyRmcXbsDFm7wlVw9iig%3D&reserved=0
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
