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 (housley@vigilsec.com) is the Document Shepherd. Sean Turner (turners@ieca.com) 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce