On 9/19/2021 3:42 AM, Julien ÉLIE wrote:
Hi all,
There is a piece missing. Yaron mentioned Alpaca. For that what we
need to say is what Alexey might fear: application protocols MUST define
ALPN labels and use them.
Reading the sentence, I also understand that applications MUST check
the ALPN label, if that extension is used.
It seems a bit too much, doesn't it?
If I understand well the use cases of ALPN, it could be used by sslh
(a ssl/ssh multiplexer) to handle connections on the same port for
different services. For instance HTTP, IMAP, POP, NNTP, etc. on the
same 443 HTTPS port.
So registering identifiers would be useful for such uses, but I am
unsure it should be considered as a MUST to check them in applications.
There are a couple of relevant references here. One is TLS 1.3 (RFC
8446). Section 4.2.10, Early Data Indication, specifies for example that
"In order to accept early data, the server ... MUST verify that the
following values are the same as those associated with the selected PSK:
... The selected ALPN [RFC7301 <https://www.rfc-editor.org/rfc/rfc7301>]
protocol. That is, session resumption tickets are specific to the
application identified by the ALPN.
The other reference is the use of TLS in QUIC (RFC 9001). Section 8.1
states that "QUIC requires that the cryptographic handshake provide
authenticated protocol negotiation. TLS uses Application-Layer Protocol
Negotiation [ALPN <https://www.rfc-editor.org/rfc/rfc9001.html#ALPN>] to
select an application protocol. Unless another mechanism is used for
agreeing on an application protocol, endpoints MUST use ALPN for this
purpose."
In practice, ALPN was widely used during the development of QUIC and
HTTP3. The HTTP3 protocol was evolving, and it was important for peers
to agree on exactly which application protocol version was being uses.
The deployments would use identifiers such as "h3-29" to state support
for draft 29 of HTTP3. Connection requests will often present a list of
multiple versions, such as "h3-27, h3-29, h3-34" to indicate possible
support of versions 27, 29 and 34 of the draft. They would also often
propose the choice between the binary format HTTP3 and the text based
test format HTTP 09 to let servers negotiate which one was appropriate.
-- Christian Huitema
-- Christian Huitema
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
