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 (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://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?