Reserving the clear ALPN Protocol ID
Cloudflare
lucaspardue.24.7@gmail.com
Cloudflare
nox@nox.paris
Internet-Draft
HTTP Alternative Services (Alt-Svc) are identified by a tuple of
Application-Protocol Layer Negotiation (ALPN) protocol identifier, a host and a
port. The wire format for Alt-Svc is defined in ABNF and encodes this tuple or
the keyword "clear", which has a special meaning. This memo reserves the ALPN
protocol identifier "clear" to reduce the chances of accidental aliasing with
the "clear" keyword.
Note to Readers
RFC EDITOR: please remove this section before publication
Source code and issues list for this draft can be found at
https://github.com/LPardue/draft-pardue-httpbis-dont-be-clear.
Introduction
HTTP Alternative Services (Alt-Svc) are identified by a
tuple of Application-Protocol Layer Negotiation (ALPN)
protocol identifier, a host and a port. The wire format for Alt-Svc is defined
in ABNF and encodes this tuple or the keyword "clear", which has a special
meaning. This memo reserves the ALPN protocol identifier "clear" to reduce the
chances of accidental aliasing with the "clear" keyword.
Conventions and Definitions
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 when, and only when, they
appear in all capitals, as shown here.
Aliasing and Avoidance
Section 3 defines the Alt-Svc header field using ABNF. It requires a
custom parser, which introduces a possibility for custom implementation errors.
The Alt-Svc header field value can either be the keyword "clear" - a special
value that invalidates cached alternative services, or a list of alt-value,
that includes an encoded ALPN protocol identifier . There is a chance
that someone unwittingly defines the ALPN protocol identifier "clear" for
genuine purposes but is unaware of the use of protocol identifiers in
Alternative Services. This could trigger Alt-Svc parser errors that might
lead to confusion between the keyword with the protocol identifier use. Since
the "clear" keyword has special meaning, confusion might lead to detrimental
effects.
To prevent unintended aliasing, this document registers the "clear" ALPN
protocol identifier. It relates to no actual application-layer protocol,
effectively reserving the code point and preventing any unintended aliasing.
Security Considerations
Broken Alt-Svc header field parsers might confuse a "clear" keyword with a
"clear" ALPN protocol identifier. This could invalidate Alternative Service
cache state but a conformant client should fall back safely as described in
Section 2.4 of .
IANA Considerations
Registration of "clear" Identification String
This document creates a new registration, "clear", in the "Application-Layer
Protocol Negotiation (ALPN) Protocol IDs" registry established in .
The "clear" string is a reserved value that does not identify any protocol:
-
Protocol:
-
Reserved
-
Identification Sequence:
-
0x63 0x6C 0x65 0x61 0x72 ("clear")
-
Specification:
-
This document
Normative References
HTTP Alternative Services
This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.
Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Acknowledgments
Your name here.