I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Sorry that this review is a few days late, I hope it is still useful. This document describes a method for using the HTTP ALPN header with the HTTP CONNECT method. HTTP CONNECT is used to ask a proxy to establish a tunnel through which other protocols (possibly HTTP, but not necessarily) can be forwarded. Once established, the client encapsulates the tunneled protocol in HTTP, sends this to the proxy, and the proxy de-encapsulates and forwards the traffic, which may or may not be encrypted. The ALPN header allows the client to tell the proxy which protocol(s) it intends to encapsulate. This ALPN header is not authenticated, and the draft makes no reference to client authentication and/or other protocol security mechanisms, so I assume this exchange is not secured in any way. In the introduction, it says "When the CONNECT method is used to establish a tunnel, the ALPN header field can be used to identify the protocol that the client intends to use with that tunnel. For a tunnel that is then secured using TLS [RFC5246], the header field carries the same application protocol label as will be carried within the TLS handshake. If there are multiple possible application protocols, all of those application protocols are indicated. The ALPN header field carries an indication of client intent only. An ALPN identifier is used here only to identify the application protocol or suite of protocols that the client intends to use in the tunnel. No negotiation takes place using this header field. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other substrates could negotiate the application protocol differently. Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header field. For example, a proxy could use the application protocol to select appropriate traffic prioritization.” The security considerations section notes that the client may falsify the ALPN header, but it also implies that this could be used as input to an authorization decision: The ALPN header field described in this document is an OPTIONAL header field. Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present. If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel. This is indistinguishable from the case where either client or proxy does not support the ALPN header field. In the last of the previously quoted paragraphs, there was a similar implication regarding policy (traffic prioritization). These both raised red flags for me (especially the use of “authorization decision”). This header is unauthenticated, and therefore not trustworthy. The client and/or a bad actor between the client/proxy can modify this. Further, unless the proxy actively compares the ALPN content to the TLS ClientHello message, those values may be different. For these reasons, the ALPN header in unreliable for use in traffic policy decisions, and for security-relevant definitions of “authorization”, should never be relied upon. Things I think should change: The draft never says what the proxy should do if the client makes one claim in the ALPN header, but then does something different (including using different ALPNs in encapsulated TLS negotiations). Seems like it should. Also, the draft seems to suggest that it is okay to use the ALPN for policy/authorization decisions. This is unreliable from a security perspective. At minimum, I think the draft should explicitly call this out. —Scott