TLS 1 2 and NIST SP 800 -56

TLS 1. 2 and NIST SP 800 -56 A 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 v 3. 1 – TLS and EAP-TLS – IPSEC – SSH v 2

NIST 800 -56 A, 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 -56 A 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 -56 A 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 -56 A 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 (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?

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: //www 1. ietf. org/mailarchive/web/tls/current/msg 00900. html

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

Questions?