Subject: Document Action: 'Suite B Profile for Transport Layer Security (TLS)' to Informational RFC (draft-salter-rfc5430bis-01.txt)

From: The IESG <[email-masked]>
Date: Sat, 12 Nov 2011 00:15:00 -0800

The IESG has approved the following document:
- 'Suite B Profile for Transport Layer Security (TLS)'
  (draft-salter-rfc5430bis-01.txt) as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-salter-rfc5430bis/

Technical Summary

   The United States Government has published guidelines for
   "NSA Suite B Cryptography", which defines cryptographic
   algorithm policy for national security applications. This
   document defines a profile of TLS which is conformant with
   Suite B.

Working Group Summary

   This document is not the product of any IETF working group.

Document Quality

   This document explains the requirements for a TLS implementation
   to be considered "Suite B conformant". There is strong consensus
   from the people that are defining that term. 

Personnel

   Russ Housley ([email-masked]) is the Document Shepherd.
   Sean Turner ([email-masked]) is the Responsible Area Director.

RFC Editor Note

Please make the following changes:

1) page 7: ClientHellomessage -> ClientHello message

2) Make the existing Annex as Annex A and add the following as Annex B:

Annex B: Changes Since RFC 5430

  The changes from RFC 5430 [RFC5430] are:

  - Moved the transitional profile for use with TLS version 1.0, TLS version 1.1 
    and DTLS version 1.0 to an Annex.

  - Removed the requirement of section 4 of RFC 5430 that a Suite B TLS 1.2
    Client offer the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 or 
    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suites.

  - A Suite B TLS system configured at a minimum level of security of 128 bits MUST use
    either use TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    with the first being preferred.  

  - A Suite B TLS system configured at a minimum level of security of 128 bits MUST 
    use either ECDSA on the secp256r1 curve with SHA-256 or ECDSA on the secp384r1 curve with SHA-384.  
    One party can authenticate with ECDSA on the secp256r1 curve and SHA-256 when the other party
    authenticates with ECDSA on the secp384r1 curve and SHA-384.   

  - A system desiring to negotiate a Suite B TLS connection at a minimum level of security of 128 bits 
    MUST generate a "Supported Elliptic Curves Extension", MUST include secp256r1 in the extension and
    SHOULD include secp384r1 in the extension.

  - A client and server, in order to verify digital signatures in a Suite B TLS system configured 
    at a minimum level of security of 128 bits, MUST support secp256r1 and SHOULD support secp384r1.

  - A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer 
    SHA-256 with ECDSA and SHOULD offer SHA-384 with ECDSA in the signature_algorithms extension.

  - Certification path validation MUST only include certificates containing an ECDSA public key on the 
    secp256r1 curve or on the secp384r1 curve.  The ECDSA public keys used in the certification path MUST be    
    in non-descending order of size from the end entity public key to the root public key.

  - A Suite B TLS server configured at a minimum level of security of 128 bits MUST include ECDSA with 
    SHA-256 and SHOULD include ECDSA with SHA-384 in the supported_signature_algorithms field of the 
    CertificateRequest message.

  - A Suite B TLS client configured at a minimum level of security of 128 bits MUST use ECDSA on the
    secp256r1 curve and SHA-256 or ECDSA on the secp384r1 curve and SHA-384.

  - A Suite B TLS server configured at a minimum level of security of 128 bits MUST use either ECDSA on the
    secp256r1 curve and SHA-256 or ECDSA on the secp384r1 curve and SHA-384 when signing the
    ServerKeyExchange message.