ietf-corpus

rfc-8740

Using TLS 1.3 with HTTP/2

D. Benjamin
date2020-02 streamIETF areawit wghttpbis statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc8740 doi10.17487/RFC8740
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.

obsoleted by

updates

Extracted elements (9)

design-rationale §1

HTTP/2 multiplexes multiple requests over a single connection, making it impossible for clients to correlate a TLS CertificateRequest with the HTTP request that triggered it — the same problem that motivated forbidding TLS 1.2 renegotiation in RFC 7540 Section 9.2.1, now extended to TLS 1.3 post-handshake authentication.

http, tls

design-rationale §3

RFC 7540 allowed renegotiation before the HTTP/2 connection preface to provide confidentiality for the client certificate. TLS 1.3 encrypts the client certificate in the initial handshake, making this pre-preface allowance unnecessary and thus the prohibition applies unconditionally.

http, tls, crypto

design-rationale §4

TLS messages whose use does not depend on interaction with the application-layer protocol (e.g., KeyUpdate) may be sent freely after the handshake completes; only those requiring application coordination (like CertificateRequest) are restricted.

http, tls

interoperability-note §3

The 'post_handshake_auth' TLS extension is advertised independently of ALPN, so its presence in a ClientHello does not indicate HTTP/2 support for post-handshake authentication. HTTP/2 clients offering HTTP/1.1 alongside HTTP/2 MAY include 'post_handshake_auth' to support HTTP/1.1 only.

http, tls

interoperability-note §4

TLS 1.3 NewSessionTicket messages are permitted after the handshake completes in HTTP/2; their interactions with HTTP early data are defined in RFC 8470 and are compatible with HTTP/2's design.

http, tls

normative-requirement §3 MUST

HTTP/2 clients MUST treat a post-handshake TLS 1.3 CertificateRequest message as a connection error of type PROTOCOL_ERROR (per Section 5.4.1 of RFC 7540).

http, tls, security

normative-requirement §4 MUST

HTTP/2 implementations MUST support TLS 1.3 KeyUpdate messages when TLS 1.3 is negotiated, as KeyUpdate only affects TLS itself and requires no application-layer interaction.

http, tls

normative-requirement §3 MUST NOT

HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages, including before the connection preface.

http, tls, security

security-consideration §5

This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication alongside HTTP/1.1, lowering the barrier for deploying TLS 1.3, which is a major security improvement over TLS 1.2.

tls, http, security