RFC 6066

Transport Layer Security (TLS) Extensions: Extension Definitions

📅 published January 2011, from ietf

Transport Layer Security (TLS) Extensions: Extension Definitions 💖

okay bestie, RFC 6066 is giving "the companion doc every TLS person needs" 🎀 It's an IETF Request for Comments, numbered 6066, written by D. Eastlake 3rd of Huawei. It's a Standards Track document, published in January 2011, and it obsoletes RFC 4366 🦋 It's part of the IETF's publishing stream, with ISSN 2070-1721.

Abstract 🦋

so the vibe here is that this doc gives you specs for TLS extensions that already exist ✨ It's meant to go with RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions it covers are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. That's the whole lineup 💅

Here's the table of contents, kept exactly as it appears in the original:

   1. Introduction ....................................................3
      1.1. Specific Extensions Covered ................................3
      1.2. Conventions Used in This Document ..........................5
   2. Extensions to the Handshake Protocol ............................5
   3. Server Name Indication ..........................................6
   4. Maximum Fragment Length Negotiation .............................8
   5. Client Certificate URLs .........................................9
   6. Trusted CA Indication ..........................................12
   7. Truncated HMAC .................................................13
   8. Certificate Status Request .....................................14
   9. Error Alerts ...................................................16
   10. IANA Considerations ...........................................17
      10.1. pkipath MIME Type Registration ...........................17
      10.2. Reference for TLS Alerts, TLS HandshakeTypes, and
            ExtensionTypes ...........................................19
   11. Security Considerations .......................................19
      11.1. Security Considerations for server_name ..................19
      11.2. Security Considerations for max_fragment_length ..........20
      11.3. Security Considerations for client_certificate_url .......20
      11.4. Security Considerations for trusted_ca_keys ..............21
      11.5. Security Considerations for truncated_hmac ...............21
      11.6. Security Considerations for status_request ...............22
   12. Normative References ..........................................22
   13. Informative References ........................................23
   Appendix A. Changes from RFC 4366 .................................24
   Appendix B. Acknowledgements ......................................25

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6066.

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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

1. Introduction ✨

The Transport Layer Security (TLS) Protocol Version 1.2 is specified in [RFC5246]. That spec has the framework for extensions to TLS, the things to think about when designing extensions (see Section 7.4.1.4 of [RFC5246]), and IANA Considerations for handing out new extension code points. It doesn't define any particular extensions except Signature Algorithms (see Section 7.4.1.4.1 of [RFC5246]) 🧚

So this document is where the existing TLS extensions get their specs 💜 It's mostly an adaptation and edit of material from RFC 4366, which covered TLS extensions for TLS 1.0 (RFC 2246) and TLS 1.1 (RFC 4346).

1.1. Specific Extensions Covered

The extensions here are all about boosting what the TLS protocol message formats can do. Other stuff, like adding new cipher suites, is put off for later 🍓

The extension types defined in this document are:

      enum {
          server_name(0), max_fragment_length(1),
          client_certificate_url(2), trusted_ca_keys(3),
          truncated_hmac(4), status_request(5), (65535)
      } ExtensionType;

Specifically, the extensions described in this document:

  • Allow TLS clients to provide to the TLS server the name of the server they are contacting. This is useful for making secure connections to servers that host multiple 'virtual' servers at a single underlying network address. 🏠
  • Allow TLS clients and servers to negotiate the maximum fragment length to be sent. This is useful because some clients have memory limits, and some access networks have bandwidth limits. 📦
  • Allow TLS clients and servers to negotiate the use of client certificate URLs. This is useful for saving memory on constrained clients. 🧠
  • Allow TLS clients to indicate to TLS servers which certification authority (CA) root keys they possess. This is useful for preventing multiple handshake failures involving TLS clients that can only store a small number of CA root keys because of memory limitations. 🔑
  • Allow TLS clients and servers to negotiate the use of truncated Message Authentication Codes (MACs). This is useful for saving bandwidth in constrained access networks. 📉
  • Allow TLS clients and servers to negotiate that the server sends the client certificate status information (e.g., an Online Certificate Status Protocol (OCSP) [RFC2560] response) during a TLS handshake. This is useful for avoiding sending a Certificate Revocation List (CRL) over a constrained access network, which saves bandwidth. 📡

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

Note that any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages. This one's important, no cap 🔥

Note also that all the extensions defined in this document are 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 extensions as it would send if it were not attempting resumption. When a client includes one or more of the defined extension types in an extended client hello while requesting session resumption:

  • The server name indication extension MAY be used by the server when deciding whether or not to resume a session as described in Section 3.
  • If the resumption request is denied, the use of the extensions is negotiated as normal.
  • If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session. 💅

1.2. Conventions Used in This Document

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

2. Extensions to the Handshake Protocol ✨

This document specifies the use of two new handshake messages, "CertificateURL" and "CertificateStatus". These messages are described in Sections 5 and 8, respectively. The new handshake message structure therefore becomes:

   enum {
       hello_request(0), client_hello(1), server_hello(2),
       certificate(11), server_key_exchange (12),
       certificate_request(13), server_hello_done(14),
       certificate_verify(15), client_key_exchange(16),
       finished(20), certificate_url(21), certificate_status(22),
       (255)
   } HandshakeType;

   struct {
       HandshakeType msg_type;    /* handshake type */
       uint24 length;             /* bytes in message */
       select (HandshakeType) {
           case hello_request:       HelloRequest;
           case client_hello:        ClientHello;
           case server_hello:        ServerHello;
           case certificate:         Certificate;
           case server_key_exchange: ServerKeyExchange;
           case certificate_request: CertificateRequest;
           case server_hello_done:   ServerHelloDone;
           case certificate_verify:  CertificateVerify;
           case client_key_exchange: ClientKeyExchange;
           case finished:            Finished;
           case certificate_url:     CertificateURL;
           case certificate_status:  CertificateStatus;
       } body;
   } Handshake;

3. Server Name Indication ✨

Okay so TLS has a real gap 🙈 There's no built-in way for a client to tell the server which name it's trying to reach. That's a problem when one IP address hosts a bunch of "virtual" servers, because the server needs to know which one you're after 🧚 This extension fixes that, bestie 💖

To provide any server names, clients MAY include an extension of type server_name in the (extended) client hello. The extension_data field of this extension SHALL contain ServerNameList, which is laid out like this:

   struct {
       NameType name_type;
       select (name_type) {
           case host_name: HostName;
       } name;
   } ServerName;

   enum {
       host_name(0), (255)
   } NameType;

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

   struct {
       ServerName server_name_list<1..2^16-1>
   } ServerNameList;

The ServerNameList MUST NOT contain more than one name of the same name_type 🚫 If the server understands the ClientHello extension but doesn't recognize the server name, it SHOULD do one of two things. It can abort the handshake by sending a fatal-level unrecognized_name(112) alert, or it can keep going with the handshake 🤷‍♀️ Sending a warning-level unrecognized_name(112) alert is NOT RECOMMENDED, because clients behave unpredictably when they get warning-level alerts 💀

If the server name the client app used doesn't match the server name on the credential the server picked, that mismatch shows up later, when the client app does server endpoint identification. At that point the app has to decide whether it's still cool to proceed 👀 TLS implementations are encouraged to make info about warning-level alerts sent or received during a handshake available to application callers 🔍 That info is genuinely useful for debugging, so yes please 🎀

Note: Earlier versions of this specification permitted multiple names of the same name_type. In practice, current client implementations only send one name, and the client cannot necessarily find out which name the server selected. Multiple names of the same name_type are therefore now prohibited. 🙅‍♀️

Right now the only server names supported are DNS hostnames. That does NOT mean TLS depends on DNS 🙅 Other name types may be added later, through an RFC that updates this document 🌈 The data structure for the host_name NameType is a variable-length vector that starts with a 16-bit length. For backward compatibility, all future data structures tied to new NameTypes MUST begin with a 16-bit length field 📏 TLS MAY treat the provided server names as opaque data and just pass the names and types up to the application 🫶

HostName holds the fully qualified DNS hostname of the server, as the client understands it. The hostname is a byte string in ASCII, with no trailing dot. That's what lets internationalized domain names work, through the A-labels defined in [RFC5890] ✨ DNS hostnames are case-insensitive, and the way to compare them is described in [RFC5890], Section 2.3.2.4 🔤

Literal IPv4 and IPv6 addresses are not permitted in HostName. Not me trying to put an IP there 🙈

It is RECOMMENDED that clients include an extension of type server_name in the client hello whenever they locate a server by a supported name type 💅

A server that gets a client hello with the server_name extension MAY use that info to pick the right certificate to send back, and/or to shape other parts of its security policy 🔐 If it does, the server SHALL include an extension of type server_name in the (extended) server hello. The extension_data field of that extension SHALL be empty 🫧

When the server decides whether to accept a request to resume a session, the contents of a server_name extension MAY be used to look up the session in the session cache 🗂️ The client SHOULD include the same server_name extension in the session resumption request that it sent in the full handshake that set up the session 🎯 A server that implements this extension MUST NOT accept the resumption request if the server_name extension contains a different name. Instead, it goes ahead with a full handshake and sets up a brand-new session 🔄 When resuming a session, the server MUST NOT include a server_name extension in the server hello 🚫

If an application negotiates a server name through an application protocol and then upgrades to TLS, and a server_name extension gets sent, the extension SHOULD contain the same name that was negotiated in the application protocol 🤝 And if the server_name is set up during the TLS session handshake, the client SHOULD NOT try to request a different server name at the application layer. One name, one vibe 💜

4. Maximum Fragment Length Negotiation

Without this extension, TLS sets a fixed maximum plaintext fragment length of 2^14 bytes 📦 Constrained clients might want to negotiate a smaller maximum fragment length, because of memory or bandwidth limits 🪫

To negotiate a smaller maximum fragment length, clients MAY include an extension of type max_fragment_length in the (extended) client hello. The extension_data field of this extension SHALL contain:

   enum{
       2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
   } MaxFragmentLength;

The value is the maximum fragment length the client wants. The allowed values for this field are 2^9, 2^10, 2^11, and 2^12 🎀

Servers that receive an extended client hello containing a max_fragment_length extension MAY accept the requested maximum fragment length by including an extension of type max_fragment_length in the (extended) server hello. The extension_data field of that extension SHALL contain a MaxFragmentLength whose value is the same as the requested maximum fragment length 🤙

If a server gets a maximum fragment length negotiation request for a value that isn't one of the allowed values, it MUST abort the handshake with an illegal_parameter alert 🚨 Same energy the other way: if a client gets a maximum fragment length negotiation response that differs from the length it asked for, it MUST also abort the handshake with an illegal_parameter alert 🙅‍♀️

Once a maximum fragment length other than 2^14 has been successfully negotiated, the client and server MUST immediately begin fragmenting messages (including handshake messages) so that no fragment larger than the negotiated length gets sent 🧩 TLS already requires clients and servers to support fragmentation of handshake messages, so you're already set 👑

The negotiated length applies for the whole session, including session resumptions ⏳

The negotiated length limits the input the record layer can process without fragmentation. That's the maximum value of TLSPlaintext.length, see [RFC5246], Section 6.2.1 📐 The record layer's output can be larger, though 👀 For example, say the negotiated length is 2^9=512. With the currently defined cipher suites (the ones defined in [RFC5246] and [RFC2712]) and null compression, the record-layer output can be at most 805 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes of padding, and 32 bytes of MAC 🧮 So in this case, a TLS record-layer peer that gets a TLS record-layer message bigger than 805 bytes MUST discard it and send a record_overflow alert, without decrypting the message 🛑

When this extension is used with Datagram Transport Layer Security (DTLS), implementations SHOULD NOT generate record_overflow alerts unless the packet passes message authentication 🦋

5. Client Certificate URLs ✨

Okay so, without this extension, TLS just says that when client auth happens, the client sends its certificates to the server during the handshake. That's fine, but it could be a lot for tiny constrained clients. Sending a URL instead means they don't have to store their certificates, which saves memory 🧠💖

To negotiate sending certificate URLs, clients MAY include an extension of type client_certificate_url in the (extended) client hello. The extension_data field of this extension SHALL be empty 🎀

(Note that you have to negotiate this first, or you'd be breaking existing TLS servers 😭)

Servers that get an extended client hello with a client_certificate_url extension MAY say they're cool with certificate URLs by including an extension of type client_certificate_url in the (extended) server hello. The extension_data field of this one SHALL also be empty 🦋

Once both sides have swapped hellos with client_certificate_url extensions and the negotiation is done, clients MAY send a CertificateURL message instead of a Certificate message, like this (see also Section 2) 💅

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;

struct {
    CertChainType type;
    URLAndHash url_and_hash_list<1..2^16-1>;
} CertificateURL;

struct {
    opaque url<1..2^16-1>;
    unint8 padding;
    opaque SHA1Hash[20];
} URLAndHash;

So url_and_hash_list is basically a list of URLs and hashes 🌈 Each url MUST be an absolute URI reference according to [RFC3986] that can be used right away to fetch the certificate(s) 🔥

When X.509 certificates are involved, there are two options:

  • If CertificateURL.type is individual_certs, each URL points to one DER-encoded X.509v3 certificate, and the URL for the client's certificate goes first 🍓
  • If CertificateURL.type is pkipath, the list has one URL pointing to a DER-encoded certificate chain, using the PkiPath type from Section 10.1 🧚

If some other certificate format is used, the spec that describes that format in TLS should define how the certificates or chains get encoded, plus any rules about their ordering 🌸

The padding byte MUST be 0x01. It's only there to keep the structure backwards compatible 🙈

The hash for each URL is the SHA-1 hash of the certificate or certificate chain. For X.509, that means the DER-encoded certificate or the DER-encoded PkiPath 💜

Also, when you're using a list of URLs for X.509 certificates, the ordering matches the TLS Certificate message (see [RFC5246], Section 7.4.2), but it's the opposite of how certificates are ordered in PkiPath. Either way, the self-signed root certificate MAY be left out of the chain, since the server must already have it to validate anything ✨

Servers that get a CertificateURL SHALL try to retrieve the client's certificate chain from those URLs and then process it as usual. A cached copy of any URL's content MAY be used, as long as its SHA-1 hash matches the hash of the cached copy 👑

Servers that support this extension MUST support the 'http' URI scheme for certificate URLs, and MAY support other schemes. Using anything other than 'http', 'https', or 'ftp' could cause unexpected problems 💀

If the protocol is HTTP, the HTTP server can be set up to use the Cache-Control and Expires directives from [RFC2616] to control whether certificates or chains get cached, and for how long 🫶

The TLS server MUST NOT follow HTTP redirects when retrieving the certificates or chain. The URLs used in this extension MUST NOT be picked in a way that depends on those redirects 🚫

If the retrieval protocol returns a MIME-formatted response (like HTTP does), then the following MIME Content-Types SHALL be used: a single X.509v3 certificate gets "application/pkix-cert" [RFC2585], and a chain of X.509v3 certificates gets "application/pkix-pkipath" (Section 10.1) 🎀

The server MUST check that the SHA-1 hash of the object retrieved from that URL (after decoding any MIME Content-Transfer-Encoding) matches the given hash. If any retrieved object has the wrong SHA-1 hash, the server MUST abort the handshake with a bad_certificate_hash_value(114) alert. This alert is always fatal 😱

Clients may choose to send either "Certificate" or "CertificateURL" after successfully negotiating the option to send certificate URLs. Being able to send a certificate directly is there so clients with multiple certificates have some flexibility 🦋

If a server can't get certificates from a given CertificateURL, it MUST send a fatal certificate_unobtainable(111) alert if it needs those certificates to finish the handshake. If the server doesn't need them, it carries on with the handshake. The server MAY send a warning-level alert in that case. Clients that get such an alert SHOULD log it and keep going with the handshake if they can 📝

6. Trusted CA Indication 🔑

Okay, this one is for constrained clients. Because of memory limits, they might only have a few CA root keys, so they could want to tell servers which root keys they've got. That way they avoid repeated handshake failures 🙌

To say which CA root keys they have, clients MAY include an extension of type trusted_ca_keys in the (extended) client hello. The extension_data field of this extension SHALL contain "TrustedAuthorities", which looks like this:

struct {
    TrustedAuthority trusted_authorities_list<0..2^16-1>;
} TrustedAuthorities;

struct {
    IdentifierType identifier_type;
    select (identifier_type) {
        case pre_agreed: struct {};
        case key_sha1_hash: SHA1Hash;
        case x509_name: DistinguishedName;
        case cert_sha1_hash: SHA1Hash;
    } identifier;
} TrustedAuthority;

enum {
    pre_agreed(0), key_sha1_hash(1), x509_name(2),
    cert_sha1_hash(3), (255)
} IdentifierType;

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

So "TrustedAuthorities" is a list of the CA root key identifiers the client has. Each CA root key gets identified in one of these ways 💅

  • "pre_agreed": no CA root key identity is supplied. 🤷‍♀️
  • "key_sha1_hash": has the SHA-1 hash of the CA root key. For DSA and ECDSA keys, that's the hash of the "subjectPublicKey" value. For RSA keys, the hash is of the big-endian byte string for the modulus, minus any leading zero-valued bytes. (This copies the key hash formats that are already used in other environments 🌈)
  • "x509_name": has the DER-encoded X.509 DistinguishedName of the CA.
  • "cert_sha1_hash": has the SHA-1 hash of a DER-encoded Certificate that contains the CA root key.

Clients can include none, some, or all of the CA root keys they have in this extension 🍓

Also, a key hash or a Distinguished Name on its own might not uniquely identify a certificate issuer. For example, a CA could have several key pairs. Here we just assume that's fine, following how TLS already uses Distinguished Names to identify certificate issuers 🤓

The option to include no CA root keys exists so a client can say it has some predefined set of CA root keys 🧚

Servers that get a client hello with the trusted_ca_keys extension MAY use that info to pick the right certificate chain to send back. If they do, the server SHALL include an extension of type trusted_ca_keys in the (extended) server hello. The extension_data field of that one SHALL be empty ✨

7. Truncated HMAC 🦋

Right now, the defined TLS cipher suites use HMAC [RFC2104] to authenticate record-layer communications. In TLS, the whole output of the hash function is used as the MAC tag. But in constrained environments, it could be nice to save bandwidth by truncating that output to 80 bits when forming MAC tags 💖

To negotiate 80-bit truncated HMAC, clients MAY include an extension of type truncated_hmac in the extended client hello. The extension_data field of this extension SHALL be empty 🎀

Servers that get an extended hello with a truncated_hmac extension MAY agree to use truncated HMAC by including an extension of type truncated_hmac, with empty extension_data, in the extended server hello 🌸

Heads up: if new cipher suites get added that don't use HMAC, and the session ends up negotiating one of them, this extension won't do anything. It is strongly recommended that any new cipher suite using a different MAC treat the MAC size as an integral part of the cipher suite definition, taking both security and bandwidth into account 🔥

If HMAC truncation was successfully negotiated during a TLS handshake, and the negotiated cipher suite uses HMAC, both the client and the server pass that fact to the TLS record layer, along with the other negotiated security parameters. After that, during the session, clients and servers MUST use truncated HMACs, calculated as specified in [RFC2104]. That means SecurityParameters.mac_length is 10 bytes, and only the first 10 bytes of the HMAC output get transmitted and checked 👑 Note that this extension doesn't change how the pseudo-random function (PRF) gets calculated for handshaking or key derivation 🫶

The negotiated HMAC truncation size applies for the whole session, including session resumptions 🌈

8. Certificate Status Request ✨

Okay so constrained clients (think tiny devices on tight networks 🧚) might want a certificate-status protocol like OCSP [RFC2560] to check whether server certificates are still valid. The goal is to skip downloading CRLs, which saves bandwidth on those networks 💅. This extension lets that info ride along inside the TLS handshake, so you save roundtrips and resources. Iconic 🫶

To say "hey, I want certificate status info," clients MAY include an extension of type status_request in the (extended) client hello. The extension_data field of this extension SHALL contain CertificateStatusRequest, which looks like this:

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;

enum { ocsp(1), (255) } CertificateStatusType;

struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions  request_extensions;
} OCSPStatusRequest;

opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;

In the OCSPStatusRequest, the ResponderIDs gives a list of OCSP responders the client trusts. A zero-length responder_id_list has a special meaning: the responders are implicitly known to the server, e.g., by prior arrangement. Extensions is a DER encoding of OCSP request extensions. 🦋

Both ResponderID and Extensions are DER-encoded ASN.1 types as defined in [RFC2560]. Extensions is imported from [RFC5280]. A zero-length request_extensions value means there are no extensions. That's different from a zero-length ASN.1 SEQUENCE, which is not valid for the Extensions type. Be careful, bestie 🙈

Now the nonce drama. [RFC2560] is unclear about how the id-pkix-ocsp-nonce OCSP extension gets encoded, so for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING. (Heads up: implementations based on an existing OCSP client will need to be checked for conformance to this requirement 😭.)

Servers that receive a client hello containing the status_request extension MAY return a suitable certificate status response to the client along with their certificate. If OCSP is requested, they SHOULD use the information in the extension when picking an OCSP responder, and they SHOULD include request_extensions in the OCSP request. 🌸

Servers send a certificate response along with their certificate by sending a CertificateStatus message immediately after the Certificate message (and before any ServerKeyExchange or CertificateRequest messages). If a server returns a CertificateStatus message, then the server MUST have included an extension of type status_request with empty extension_data in the extended server hello. The CertificateStatus message is conveyed using the handshake message type certificate_status as follows (see also Section 2):

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;

opaque OCSPResponse<1..2^24-1>;

An ocsp_response contains a complete, DER-encoded OCSP response (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one OCSP response may be sent. 💜

Note that a server MAY also choose not to send a CertificateStatus message, even if it has received a status_request extension in the client hello message and has sent a status_request extension in the server hello message.

Note in addition that a server MUST NOT send the CertificateStatus message unless it received a status_request extension in the client hello message and sent a status_request extension in the server hello message. That's a hard no, no cap 🚫

Clients who requested an OCSP response and got one in a CertificateStatus message MUST check the OCSP response. If it's not satisfactory, they MUST abort the handshake with the bad_certificate_status_response(113) alert. This alert is always fatal. Periodt 💀

9. Error Alerts

Four new error alerts are defined for the TLS extensions in this document. To avoid "breaking" existing clients and servers, these alerts MUST NOT be sent unless the sending party has received an extended hello message from the party it's communicating with. 🎀 They're conveyed using the syntax below. The new alerts are the last four, as the comments on their lines show.

enum {
    close_notify(0),
    unexpected_message(10),
    bad_record_mac(20),
    decryption_failed(21),
    record_overflow(22),
    decompression_failure(30),
    handshake_failure(40),
    /* 41 is not defined, for historical reasons */
    bad_certificate(42),
    unsupported_certificate(43),
    certificate_revoked(44),
    certificate_expired(45),
    certificate_unknown(46),
    illegal_parameter(47),
    unknown_ca(48),
    access_denied(49),
    decode_error(50),
    decrypt_error(51),
    export_restriction(60),
    protocol_version(70),
    insufficient_security(71),
    internal_error(80),
    user_canceled(90),
    no_renegotiation(100),
    unsupported_extension(110),
    certificate_unobtainable(111),        /* new */
    unrecognized_name(112),               /* new */
    bad_certificate_status_response(113), /* new */
    bad_certificate_hash_value(114),      /* new */
    (255)
} AlertDescription;

Where to find the new ones:

  • certificate_unobtainable is described in Section 5.
  • unrecognized_name is described in Section 3.
  • bad_certificate_status_response is described in Section 8.
  • bad_certificate_hash_value is described in Section 5.

10. IANA Considerations

IANA Considerations for TLS extensions and the creation of a registry are covered in Section 12 of [RFC5246], except for the registration of the MIME type application/pkix-pkipath, which appears below. ✨

The IANA TLS extensions and MIME type application/pkix-pkipath registry entries that reference RFC 4366 have been updated to reference this document. Glow-up era 🌈

10.1. pkipath MIME Type Registration

Here's the registration, bestie:

MIME media type name: application
MIME subtype name: pkix-pkipath
Required parameters: none

Optional parameters: version (default value is "1")

Encoding considerations: It's binary! This type is a DER encoding of the ASN.1 type PkiPath, defined as:

PkiPath ::= SEQUENCE OF Certificate

PkiPath is used to represent a certification path. Inside the sequence, the certificates are ordered so that the subject of the first certificate is the issuer of the second certificate, etc. This is identical to the definition published in [X509-4th-TC1]. Note that it's different from the one in [X509-4th]. 🦋

All Certificates MUST conform to [RFC5280]. (This should be interpreted as a requirement to encode only PKIX-conformant certificates using this type. It does not necessarily require that all certificates that are not strictly PKIX-conformant must be rejected by relying parties, although the security consequences of accepting any such certificates should be considered carefully.) Be careful, babe 🙈

DER (as opposed to BER) encoding MUST be used. If this type is sent over a 7-bit transport, base64 encoding SHOULD be used.

Security considerations: The security considerations of [X509-4th] and [RFC5280] (or any updates to them) apply, as well as those of any protocol that uses this type, e.g., TLS. ⚠️ This type only specifies a certificate chain that can be assessed for validity according to the relying party's existing configuration of trusted CAs. It is not intended to be used to specify any change to that configuration.

Interoperability considerations: No specific interoperability problems are known with this type. For recommendations about X.509 certificates in general, see [RFC5280].

Published specification: This document and [RFC5280].

Applications that use this media type: TLS. It may also be used by other protocols or for general interchange of PKIX certificate chains.

Additional information:

  • Magic number(s): DER-encoded ASN.1 can be easily recognized. Further parsing is required to tell it apart from other ASN.1 types.
  • File extension(s): .pkipath
  • Macintosh File Type Code(s): not specified

Person & email address to contact for further information: Magnus Nystrom <mnystrom@microsoft.com>

Intended usage: COMMON

Change controller: IESG <iesg@ietf.org>

10.2. Reference for TLS Alerts, TLS HandshakeTypes, and ExtensionTypes

The following values in the TLS Alert Registry have been updated to reference this document:

111 certificate_unobtainable
112 unrecognized_name
113 bad_certificate_status_response
114 bad_certificate_hash_value

The following values in the TLS HandshakeType Registry have been updated to reference this document:

21 certificate_url
22 certificate_status

The following ExtensionType values have been updated to reference this document:

0 server_name
1 max_fragment_length
2 client_certificate_url
3 trusted_ca_keys
4 truncated_hmac
5 status_request

11. Security Considerations 🔐

General security considerations for TLS extensions are covered in [RFC5246]. Security considerations for the particular extensions specified in this document are given below. Stay alert, because the threat landscape never sleeps 👑

In general, implementers should continue to monitor the state of the art and address any weaknesses that are identified. Don't get complacent 💅

11.1. Security Considerations for server_name

If a single server hosts several domains, then it's clearly necessary for the owners of each domain to make sure this satisfies their security needs. Apart from that, server_name doesn't appear to introduce significant security issues. ✨

It's possible for a client to present a different server_name in the application protocol. So application server implementations that rely on these names being the same MUST check that the client did not present a different name in the application protocol. This is a big deal 😭

Implementations MUST ensure that a buffer overflow does not occur, whatever the values of the length fields in server_name. Non-negotiable, bestie 💀

11.2. Security Considerations for max_fragment_length

The maximum fragment length takes effect immediately, including for handshake messages. That doesn't introduce any security complications that aren't already present in TLS, since TLS requires implementations to be able to handle fragmented handshake messages. 🧚

As described in Section 4, once a non-null cipher suite has been activated, the effective maximum fragment length depends on the cipher suite and compression method, as well as on the negotiated max_fragment_length. This must be taken into account when sizing buffers and checking for buffer overflow. Buffer sizing is not the place to vibe-check 🙈🔥

11.3. Security Considerations for client_certificate_url 🔐

Okay bestie, so supporting client_certificate_url means the server is basically acting as a client in another URI-scheme-dependent protocol 🫣. That means it picks up a lot of the same security worries that clients of that scheme deal with, PLUS an extra one: the client can try to make the server connect to some possibly weird-looking URL. Not it. 💀

In general, this means an attacker could use your server to indirectly attack another host that has some security flaw. It also opens the door to denial-of-service attacks, where an attacker makes tons of connections to the server and each one makes the server try to connect to the attack's target. Chaotic. 😭

The server might also be sitting behind a firewall, or be able to reach hosts that aren't directly accessible from the public Internet. Which is lowkey scary, because it could make all those security and denial-of-service problems worse, and it could let someone confirm that internal hosts exist when they'd otherwise stay hidden 🙈.

The exact concerns depend on which URI schemes the server supports. For HTTP, it's similar to the concerns for a publicly accessible HTTP proxy server. For HTTPS, loops and deadlocks may be created, and this should be addressed. For FTP, you get attacks that are similar to FTP bounce attacks 🌀.

So, as a result of all this, it is RECOMMENDED that the client_certificate_url extension should have to be specifically enabled by a server administrator, rather than being enabled by default ✨. It is also RECOMMENDED that URI schemes be enabled by the administrator individually, and that only a minimal set of schemes be enabled. Unusual protocols that offer limited security, or whose security isn't well understood, SHOULD be avoided 🛡️.

As discussed in [RFC3986], URLs that specify ports other than the default may cause problems, and so may very long URLs (which are more likely to be useful for exploiting buffer overflow bugs) 💅.

This extension continues to use SHA-1 (as in RFC 4366) and does not provide algorithm agility. The property required of SHA-1 in this case is second pre-image resistance, NOT collision resistance 🧠. Even if second pre-image attacks against SHA-1 are found in the future, an attack against client_certificate_url would still need a second pre-image that is accepted as a valid certificate by the server and contains the same public key.

Also, HTTP caching proxies are super common on the Internet, and some of them don't check for the latest version of an object correctly 👀. If a request using HTTP (or another caching protocol) goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response.

11.4. Security Considerations for trusted_ca_keys 🗝️

Potentially, the CA root keys a client has could be regarded as confidential information, so the CA root key indication extension should be used with care 🤫.

The SHA-1 certificate hash alternative makes sure each certificate is specified unambiguously. This context doesn't require a cryptographic hash function, so using SHA-1 is considered acceptable, and no algorithm agility is provided 💖.

11.5. Security Considerations for truncated_hmac ✂️

It is possible that truncated MACs are weaker than "un-truncated" MACs. However, no significant weaknesses are currently known or expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits 🦋.

Also, the output length of a MAC doesn't need to be as long as a symmetric cipher key, since forging MAC values can't be done off-line. In TLS, a single failed MAC guess causes the immediate termination of the TLS session. Iconic behaviour 💅.

Since the MAC algorithm only takes effect after all handshake messages that affect extension parameters have been authenticated by the hashes in the Finished messages, it is NOT possible for an active attacker to force negotiation of the truncated HMAC extension where it wouldn't otherwise be used (to the extent that the handshake authentication is secure) 🔒. So, if any security problems were found with truncated HMAC in the future, and either the client or the server for a given session were updated to take the problem into account, that side would be able to veto use of this extension 🙌.

11.6. Security Considerations for status_request 📜

If a client requests an OCSP response, it must take into account that an attacker's server using a compromised key could (and probably would) pretend not to support the extension 😬. In this case, a client that requires OCSP validation of certificates SHOULD either contact the OCSP server directly or abort the handshake.

Using the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that try to replay OCSP responses. See Section 4.4.1 of [RFC2560] for further details 🌸.

12. Normative References 📚

  • [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
  • [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.

13. Informative References 🧚

  • [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
  • [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, "Information Systems - Open Systems Interconnection - The Directory: Public key and attribute certificate frameworks".
  • [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC 9594:8:2001.

Appendix A. Changes from RFC 4366 🎀

The significant changes between RFC 4366 and this document are described below. Let's go!! 🚀

RFC 4366 described both general extension mechanisms (for the TLS handshake and client and server hellos) as well as specific extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The client and server hello extension mechanisms have been moved into RFC 5246, TLS 1.2, so this document, which is associated with RFC 5246, includes only the handshake extension mechanisms and the specific extensions from RFC 4366. RFC 5246 also specifies the unknown extension error and new extension specification considerations, so that material has been removed from this document 📦.

The Server Name extension now specifies only ASCII representation, eliminating UTF-8. It is provided that the ServerNameList can contain more than only one name of any particular name_type. If a server name is provided but not recognized, the server should either continue the handshake without an error or send a fatal error. Sending a warning-level message is not recommended because client behavior will be unpredictable. Provision was added for the user using the server_name extension in deciding whether or not to resume a session. Furthermore, this extension should be the same in a session resumption request as it was in the full handshake that established the session. Such a resumption request must not be accepted if the server_name extension is different, but instead a full handshake must be done to possibly establish a new session 🫶.

The Client Certificate URLs extension has been changed to make the presence of a hash mandatory 🔐.

For the case of DTLS, the requirement to report an overflow of the negotiated maximum fragment length is made conditional on passing authentication 🧩.

TLS servers are now prohibited from following HTTP redirects when retrieving certificates 🚫.

The material was also re-organized in minor ways. For example, information as to which errors are fatal is moved from the "Error Alerts" section to the individual extension specifications 🗂️.

Appendix B. Acknowledgements 💜

This document is based on material from RFC 4366, for which the authors were S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright. Other contributors include Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian Farrel. Huge thank yous to all of them 🥹🫶.

Author's Address 🖋️

Donald Eastlake 3rd
Huawei
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
📦 where this page comes from