TLS 1.2 and NIST SP 800-56A

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 Were Here

• This is clearly a bad situation
• The WG chair reviewed the 800-56A KDF and
  determined it isnt 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/800-56A
  /sp800-56A_May-3-06.pdf
• Personal draft with KDFs
• http//www.ietf.org/internet-drafts/draft-dang-nis
  tkdf-01.txt

16
Questions?