1. TLS 1.2 and NIST SP 800-56A Tim Polk November 10, 2006

2. Acknowledgements The bulk of the analysis was performed by Ray Perlner at NIST Reviewed -01 draft

3. Background NIST publishes cryptographic standards and specifications –Agencies protecting unclassified data with cryptography need to use Approved algorithms Based on FIPS 140, FISMA, etc.. –Exception: where no Approved algorithms exist, agencies can select any algorithm CMVP may impose additional constraints

4. FIPS 140 Implementation Guidance, 12/2005 “The following protocols are acceptable for use in the FIPS mode to establish keys to be used for encryption and decryption:” –SSL v3.1 –TLS and EAP-TLS –IPSEC –SSH v2

5. NIST 800-56A, Key Establishment Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography –Published March, 2006 Specifies key derivation function(s) –Basically, one kdf with two input formatting variants (ASN.1 and concatenated values)

6. 800-56A KDF Overview.. Generate keying material with a hash function from the shared secret and… –Cryptographic algorithm(s) identifier –Identifiers for communicating parties –Nonces (required if keys are static) –Optional information from both parties The derived key material is bound to the complete communications context

7. Silence Was Golden Now that we specify a kdf… the FIPS 140 IG will be changing Current proposal: –Accept protocols with 800-56A KDF No such protocols exist –Review protocols that use non-conforming KDFs, accept with time limits TLS is proposed for acceptance through the end of 2010

8. Now That We’re Here… This is clearly a bad situation –The WG chair reviewed the 800-56A KDF and determined it isn’t a good fit for TLS –The AD requested that NIST reconsider the problem Could NIST accept the TLS kdf without an expiration date?

9. Analysis NIST could accept TLS 1.2 without an expiration date, with a few minor fixes Finished message binds the context to the communications channel effectively –Niche cases exist where these bindings might not be established

10. Certificate Hash Certificate hash needs to be mandatory –If the hash is not included with the client certificate URL, the finished message will not factor in the name associated with the key. Hash needs agility –The protocol mandates SHA-1, which is fine as a default, but there is no mechanism to specify a stronger algorithm.

11. Upgrade Security Guidance to Requirements TLS recommends mechanisms to protect against –Timing attacks (6.2.3.2, 7.4.9.1) –Bliechenbacher attack (7.4.9.1) Can TLS 1.2 upgrade these to MUST? Consider extending guidance for blinding to non-RSA key exchange algorithms?

12. Clarifications in Error Handling Need to clarify when alerts MUST be sent versus MAY be sent –Responses on list have been helpful; would like to see this information in the spec

13. Incremental Changes IVs –MUST use one of the specified IV generation techniques Certificate Handling, HMAC truncation –Should require explicit agreement DH –Recommend maintaining leading zeroes

14. Anonymous Diffie-Hellman Frankly, it makes us nervous. List traffic does not support expunging Anonymous DH –Need to ensure that Anonymous DH is only used with user agreement –Bodo Moeller has suggested text: http://www1.ietf.org/mail- archive/web/tls/current/msg00900.html

15. Further Information NIST 800-56A (see 5.8) –http://csrc.nist.gov/publications/nistpubs/80 0-56A/sp800-56A_May-3-06.pdfhttp://csrc.nist.gov/publications/nistpubs/80 0-56A/sp800-56A_May-3-06.pdf Personal draft with KDFs –http://www.ietf.org/internet-drafts/draft- dang-nistkdf-01.txthttp://www.ietf.org/internet-drafts/draft- dang-nistkdf-01.txt

16. Questions?