TLS 1.2 and NIST SP 800-56A Tim Polk November 10, 2006 Acknowledgements • The bulk of the analysis was performed by Ray Perlner at NIST • Reviewed -01 draft 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 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 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) 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 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 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? 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 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. Upgrade Security Guidance to Requirements • TLS recommends mechanisms to protect against – Timing attacks (220.127.116.11, 18.104.22.168) – Bliechenbacher attack (22.214.171.124) • Can TLS 1.2 upgrade these to MUST? • Consider extending guidance for blinding to non-RSA key exchange algorithms? 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 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 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/mailarchive/web/tls/current/msg00900.html Further Information • NIST 800-56A (see 5.8) – http://csrc.nist.gov/publications/nistpubs/80 0-56A/sp800-56A_May-3-06.pdf • Personal draft with KDFs – http://www.ietf.org/internet-drafts/draftdang-nistkdf-01.txt Questions?