TLS Extension for out-of-band public key validation
draft-wouters-tls-oob-pubkey-00

Abstract

This document specifies a new TLS extension as well as modified TLS client and TLS server behaviour when public keys are authenticated out-of-band to the current TLS connection. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The new extension specified is "oob_pubkey_list" which can be used when the TLS client is already in possession of a validated public key of the TLS server before it starts the TLS handshake.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 05, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Motivation
• 1.2. Applicability
• 1.3. Terminology
• 1.4. Specific Extension Covered
• 2. TLS extension specifying Out-of-band public key retrieval
• 3. Security Considerations
• 4. IANA Considerations
• 5. Contributors
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

1.1. Motivation

Traditionally, TLS server public keys are obtained in PKIX containers in-band using the TLS connection and validated using trust anchors based on a [PKIX] certification authority (CA). This method can add a complicated trust relationship that is difficult to validate. Examples of such complexity can be seen in [Defeating-SSL].

Alternative methods are available that allow a TLS client to obtain the TLS server public key:

• The TLS server public key is obtained from a [PKIX] certificate chain from an [LDAP] server
• The TLS server public key is obtained from a DNSSEC secured RRset using [DANE]
• The TLS server public key is provisioned by the operating system and updated via software updates
• A TLS client has connected to the TLS server before and has cached the TLS server certificate chain or TLS server public key for re-use

[RFC5246] does not provide a mechanism for a TLS client to tell the TLS server it is already in possession of the authenticated public key. Therefore, a TLS server must always send a list of trusted CA keys and its EE certificate containing its public key, even when the TLS client does not require or desire that data for authentication.

[RFC6066] allows suppression of the certificate trust anchor chain, but not suppression of the PKIX EE certificate container. These certificate chains are large opague blocks of data containing much more then the public key of the TLS server. Since the TLS client might only be able to validate the PKIX SubjectPublicKeyInfo via an out-of-band method, it has to explicitly forget any additional information received that was sent by the server that it could not validate. Furthermore, information that comes in via these certificate chains could contain contradicting or additional information that the TLS client cannot validate or trust, such as an expiry date that conflicts with information obtained from DNS or LDAP. This document specifies a method to suppress sending this additional information.

1.2. Applicability

The Transport Layer Security (TLS) Protocol Version 1.2 is specified in RFC 5246 [RFC5246]. RFC 5246 also provides a framework for extensions to TLS as well as considerations for designing such extensions. RFC 6066 [RFC6066] defines several new TLS extensions. This document extends the specifications of those RFCs with one new TLS extension to facilitate suppressing unneeded [PKIX] information from being sent during the TLS handshake when this information is not required to authenticate the TLS server.

1.3. Terminology

Most security-related terms in this document are to be understood in the sense defined in [SECTERMS]; such terms include, but are not limited to, "attack", "authentication", "authorization", "certification authority", "certification path", "certificate", "credential", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify".

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.4. Specific Extension Covered

The extension described here describes a method for the TLS client to instruct the TLS server to omit sending the PKIX End Entity certificate and trusted root CA certificates.

        enum {
          oob_pubkey_list([TBD]) (65535)
        } ExtensionType;

        

The extension type is defined in this document are:

TLS clients and TLS servers may use the extension described in this document. The extension is designed to be backwards compatible, meaning that TLS clients that support the extension can talk to TLS servers that do not support the extension, and vice versa.

Note that any messages associated with this extension that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages.

Note also that the extension defined in this document is relevant only when a session is initiated. A client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extension as it would send if it were not attempting resumption. When a client includes the defined extension type in an extended ClientHello while requesting session resumption, the server MUST, when agreeing to resume the older session, ignore the extension and send a ServerHello that does not contain the extension. In this case, the functionality of this extension negotiated during the original session initiation is applied to the resumed session. If the resumption request is denied, the use of the extension is negotiated as normal.

2. TLS extension specifying Out-of-band public key retrieval

In order to indicate which server public keys they trust, clients MAY include an extension of type "oob_pubkey_list" in the (extended) ClientHello. The "extension_data" field of this extension SHALL contain "PublicKeyList" where:

      struct {
          IdentifierType identifier_type;
          select (identifier_type) {
              case key_raw_pubkey: subjectPublicKeyInfo;
              case key_sha256_hash: SHA256Hash;
          } identifier;
      } PublicKey;

      enum {
          key_raw_pubkey(0), key_sha1_hash(1) (255)
      } IdentifierType;

      opaque subjectPublicKeyInfo<1..2^16-1>;  

      opaque SHA256Hash<32>;

       struct {
          PublicKey public_key_list<1..2^16-1>
       } PublicKeyList;


      

In each entry in the list, the client can either include the full public key, in the form of a subjectPublicKeyInfo (see RFC 2528 [RFC2528] and RFC 5480 [RFC5480]) or a SHA-256 hash of the subjectPublicKeyInfo. The PublicKeyList MUST contain at least one PublicKey entry.

The TLS server MAY respond with an extension of type "oob_pubkey_list" in the (extended) server hello. The "extension_data" field of this extension SHALL contain "PublicKeyList" containing exactly one of the "PublicKey" identifiers used in the received client hello message. It SHALL use the same IdentifierType as the TLS client used to send the identifier to the TLS server. It MUST NOT send and empty PublicKeyList.

If the TLS server responds with an extension of type "oob_pubkey_list", it SHOULD omit sending a "Server Certificate" message.

If the TLS server does not respond with an extension of type "oob_pubkey_list", the TLS client MUST assume the extension is not supported. The TLS client MAY fall back to using in-band PKIX validation. If the TLS client cannot fallback to PKIX authentication, it MUST abort the TLS handshake.

3. Security Considerations

The TLS extension defined here lets a TLS client attempt to supress the sending of server certificate as well as the certification chain for that certificate.

A client using this extension needs to be confident in the authenticity of the public key it is using. Since those public keys were obtained out-of-band (hence the name of the extension), the authentication must also be out-of-band.

Depending on exactly how the public keys were obtained, it may be appropriate to use authentication mechanisms tied to the public key transport. For example, if public keys were obtained using [DANE] it is appropriate to use DNSSEC to authenticate the public keys.

4. IANA Considerations

We request that IANA assign a TLS Extension Type value for oob_pubkey_list

5. Contributors

The following individuals made important contributions to this document: Paul Hoffman.

6. Acknowledgements

This document is based on material from RFC 6066 for which the author is Donald Eastlake 3rd. Contributions to that document also include Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian Farrel.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses