TLS 1.2 and NIST SP 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 v3.1 –TLS and EAP-TLS –IPSEC –SSH v2

NIST 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-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 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 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 ( , ) –Bliechenbacher attack ( ) 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: archive/web/tls/current/msg00900.html

Further Information NIST A (see 5.8) – 0-56A/sp800-56A_May-3-06.pdfhttp://csrc.nist.gov/publications/nistpubs/ A/sp800-56A_May-3-06.pdf Personal draft with KDFs – dang-nistkdf-01.txthttp:// dang-nistkdf-01.txt

Questions?