Extensible Pre-Shared Key Types for TLS

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 https://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 21 January 2021.¶

Copyright Notice

Copyright (c) 2020 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 (https://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

TLS 1.3 [RFC8446] currently supports two "types" of Pre-Shared Keys (PSKs): resumption and external PSKs. Resumption PSKs carry state from previous connections, typically in the form of tickets, for PSK-based authentication. External PSKs are opaque to TLS and defined by applications.¶

There is no signal on the wire that indicates the type of PSK offered in a ClientHello. Rather, endpoints differentiate these PSKs by augmenting the TLS key schedule with a domain-separation label depending on the type negotiated. Since these labels are fixed, this makes integration of new PSK types difficult.¶

There are several reasons why one might want alternative PSK types. Below are three examples:¶

• Forward-secure external PSKs. Repeated use of an external PSK is a security concern for connections that use 0-RTT data or do not additionally perform a fresh key exchange. To mitigate this risk, endpoints could ratchet forward external PSKs after each use. TLS should support forward-secure external PSKs.¶
• 0-RTT priming. QUIC Crypto [QUICCrypto] specified a signed Server Config structure which contained, among other data, semi-static key shares and corresponding algorithm information. After verifying this config signature, clients may then use these semi-static key shares to perform a non-interactive key exchange and produce a shared secret. They may also then encrypt early data for to the server using this shared secret. Using these authenticated key shares, clients can prime connections for early data support without having previously connected to the target server. TLS should support priming 0-RTT data without having previously connected to a server.¶

Pre-distributed keys for 0-RTT priming also have positive privacy implications, as servers cannot tie these keys to past connections using TLS-layer state. (Resumption PSKs allow servers to track clients across connection attempts.)¶

• Server authentication priming. KEMTLS [KEMTLS] uses static Key Encapsulation Mechanism public keys for server authentication. In the normal flow, these keys are sent in the server Certificate message. However, similar to QUIC Crypto, if these keys are available a priori from a trusted source, they may be used by clients in the first handshake flight. TLS should support priming clients with server authentication information to accelerate full handshakes.¶

Given these shortcomings, this document defines the Extended PSK Identity extension, to support these emerging use cases. This extension allows for new types of PSKs. This document also specifies two new PSK types, referred to as "ratcheted" and "kem" PSKs, which address the use cases described above.¶

2. Requirements Notation

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Extended PSKs Types

Endpoints identify extended PSKs by their type. The following enumeration specifies a preliminary set of extended PSK types.¶

enum {
    ratcheted(0),
    kem(1),
    (255)
} ExtendedPskIdentityType;

The following sections describe the "ratcheted" and "kem" PSK types in more detail.¶

struct {
    opaque identity<1..2^16-1>;
    uint32 generation;
} RachetedPSKIdentity;

   struct {
       ProtocolVersion version;
       CipherSuite cipher_suite;
       HPKEPublicKey hpke_init_key;
       Credential credential;
       Extension extensions<0..2^16-1>;
       opaque signature<0..2^16-1>;
   } KeyPackage;

pkR = HPKE.KEM.Unmarshal(KeyPackage.hpke_init_key)
enc, context = SetupBaseS(pkR, "RFCXXXX-psk-kem")
kem_psk = context.Export("tls13-extended-psk-kem", L)

struct {
    opaque package_digest<0..2^16-1>;
    opaque enc<1..2^16-1>;
} KEMPSKIdentity;

4. Extended PSK Identity

Clients may signal possession of an extended PSK via the "extended_psk" extension:¶

   enum {
       extended_psk(TBD), (65535)
   } ExtensionType;

Clients MAY send this extension in ClientHello. It contains the following ExtendedPreSharedKeyExtension structure:¶

struct {
    ExtendedPSKIdentityType type;
    switch (PskIdentity.type) {
        external:
            opaque identity<1..2^16-1>;
        case resumption:
            opaque identity<1..2^16-1>;
            uint32 obfuscated_ticket_age;
        case ratcheted:
            RachetedPSKIdentity ratcheted_identity;
        case package:
            KeyPackage key_package;
    } ExtendedPskIdentityInner;
} ExtendedPskIdentity;

struct {
    ExtendedPskIdentity identities<2..2^16-1>;
    PskBinderEntry binders<33..2^16-1>;
} ExtendedOfferedPsks;

struct {
    select (Handshake.msg_type) {
        case client_hello: ExtendedOfferedPsks;
        case server_hello: uint16 selected_identity;
    };
} ExtendedPreSharedKeyExtension;

[[OPEN ISSUE: should clients be allowed to send both regular and extended PSK identities?]]¶

Servers which support the "extended_psk" structure MUST parse its ExtendedPskIdentity types according to their type. Servers MUST use the resulting identity as they would the PskIdentity extension in [RFC8446]. While parsing ExtendedPskIdentity values, servers MUST ignore PSK types they do not support. Servers SHOULD ignore PSK values they do not recognize, e.g., due to loss of a corresponding key needed to process the PSK, and SHOULD NOT attempt to validate more than one PSK, per the guidance in [RFC8446], Section 4.2.11.¶

Clients MUST verify the server's selected identity in accordance with the rules outlined in [RFC8446].¶

5. Design Considerations

One could extend the existing PskIdentity extension in TLS 1.3 [RFC8446], yet doing so requires additional signalling that may be unnecessary. Extended PSK types are likely only to be supported by newer stacks, which can easily add a new extension codepoint.¶

6. Security Considerations

[[TODO: writeme]]¶

7. IANA Considerations

[[TODO: writeme]]¶

Appendix A. Acknowledgements

[[TODO: writeme]]¶

Authors' Addresses