Draft: draft-ietf-quic-http

Commentary: While the changes to SEMANTICS are still in flight , that does n't necessarily block resolving the issues in HTTP/3 . We can point to SEMANTICS normatively and defer to whatever resolution lands there , trusting it will be reasonable . Paging and Key changes here : Rather than defining how the certificate is validated , defer to Section 4.3.4 of SEMANTICS ( which will likely be something like ) Require clients to re - perform validation for each new origin that this implies retaining the cert chain . ... suggesting that clients encountering failures might choose to re - perform validation for origins already tied to the connection ( e.g. cert is expired , revoked , etc . ) Require clients to re - perform validation for new origins being pushed at them , just as they would before sending a request 
 Thanks for the revisions . Consider my ballot comments captured in and resolved . 
 Spotted in While we do n't need to make any dependency on h2bis , I do n't think it ould hurt to update the reference to 421 to point at http - core . 
 Labeling as design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 said 
 I think that the main concern here is addressed by a change - or addition - to the text that  quoted . That is , we change from the determination of authority being made universally based on the set of names in the certificate ( a passive determination , if you will ) to the per - name , query - based approach that we generally have ( an active seeking of authority ) . As the quoted text could be read as non - normative when placed besides more specific text with clear normative force . The other points might benefit from clarification , but the problem largely stems from this passive definition of authority . Regarding revocation checks that succeed at handshake time , but fail later , I would suggest the answer only affects the determination of authority for the name that is queried . That is consistent with the per - name , query - based approach . The idea that the connection might be torn down is not consistent with that . 
 Labeling as design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 review of -http identified use of the subject : commonName field in validating server identity . We should not elevate CN - ID to MUST . In doing so , we invalidate what  has done : 7.1.4.2.2 clause a of the marks subject : commonName as deprecated and discouraged . My understanding ( which I can confirm ) is that browsers do not use CN - ID ( concretely , the CN field of the certificate subject ) and so we might want to just mention the dNSName type of subjectAltName here . We can mention that some clients might use subject : commonName , but that this is a deprecated practice . This accounts for some of the older certificate validation code that still exists in some places . Some of that does rely on the common name . I realize that this likely breaks new ground for the RFC series , and it likely needs more discussion , but maybe we can keep up with the times with this document . ( I apologize for not having caught this earlier ; I think that this is copied from elsewhere and that too needs a refresh . ) Originally posted by in 
 There is some probably relevant discussion for http - semantics at ( though as was noted recently the change that closed that issue had some issues of its own ) 
 Marking as design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 said 
 Agreed , this should point back if it does n't already . This probably also gets swept up in the resolution to , but it 's a separate point I 'll need to make sure is addressed . 
 Labeling as design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 said 
 I suspect this will be fixed by the resolution to . 
 FWIW I have some changes staged in my forthcoming editorial PR that harmonizes the requirements language here , even though that is perhaps a little speculative for " just " an editorial PR . 
 Labeling this design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor . 
 notes that while we imported text from SEMANTICS in about what makes a server authoritative , this text later changed dramatically in and we 're no longer aligned . We need to re - sync , but only after is fixed . 
 Labeling as design , since is . 
 Reopening for consensus call . 
 Closing this now that the IESG have approved the document and it 's with the RFC editor .
Paragraph (version B):
Because HTTP/1.1 does not include a multiplexing layer, multiple TCP
connections are often used to service requests in parallel.  However,
that has a negative impact on congestion control and network
efficiency, since TCP does not share congestion control across
multiple connections.
Paragraph (version A):
This document defines a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on the design of HTTP/2.  While
delegating stream lifetime and flow control issues to QUIC, a similar
binary framing is used on each stream.  Some HTTP/2 features are
subsumed by QUIC, while other features are implemented atop QUIC.
Paragraph (version A):
Within each stream, the basic unit of HTTP/3 communication is a frame
(frames).  Each frame type serves a different purpose.  For example,
HEADERS and DATA frames form the basis of HTTP requests and responses
(request-response).
Paragraph (version A):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URL is discussed in Section 4.3 of SEMANTICS.
Paragraph (version A):
If a server presents a valid certificate and proof that it controls
the corresponding private key, then a client will accept a secured
TLS session with that server as being authoritative for all origins
with the "https" scheme and a host identified in the certificate.
The host must be listed either as the CN field of the certificate
subject or as a dNSName in the subjectAltName field of the
certificate; see RFC6125.  For a host that is an IP address, the
client MUST verify that the address appears as an iPAddress in the
subjectAltName field of the certificate.
Paragraph (version A):
If the hostname or address is not present in the certificate, the
client MUST NOT consider the server authoritative for origins
containing that hostname or address.  See Section 4.3 of SEMANTICS
for more detail on authoritative access.
Paragraph (version B):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URI.  Upon receiving a
server certificate in the TLS handshake, the client MUST verify that
the certificate is an acceptable match for the URI's origin server
using the process described in Section 4.3.4 of SEMANTICS.  If the
certificate cannot be verified with respect to the URI's origin
server, the client MUST NOT consider the server authoritative for
that origin.
Paragraph (version B):
Servers MAY serve HTTP/3 on any UDP port; an alternative service
advertisement always includes an explicit port, and URIs contain
either an explicit port or a default port associated with the scheme.
Paragraph (version A):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
Clients SHOULD NOT open more than one HTTP/3 connection to a given
host and port pair, where the host is derived from a URI, a selected
alternative service (ALTSVC), or a configured proxy.  A client MAY
open multiple HTTP/3 connections to the same IP address and UDP port
using different transport or TLS configurations but SHOULD avoid
creating multiple connections with the same configuration.
Paragraph (version B):
Once a connection exists to a server endpoint, this connection MAY be
reused for requests with multiple different URI authority components.
To use an existing connection for a new origin, clients MUST validate
the certificate presented by the server for the new origin server
using the process described in Section 4.3.4 of SEMANTICS.  This
implies that clients will need to retain the server certificate and
any additional information needed to verify that certificate; clients
which do not do so will be unable to reuse the connection for
additional origins.
Paragraph (version B):
If the certificate is not acceptable with regard to the new origin
for any reason, the connection MUST NOT be reused and a new
connection SHOULD be established for the new origin.  If the reason
the certificate cannot be verified might apply to other origins
already associated with the connection, the client SHOULD re-validate
the server certificate for those origins.  For instance, if
validation of a certificate fails because the certificate has expired
or been revoked, this might be used to invalidate all other origins
for which that certificate was used to establish authority.
Paragraph (version B):
Clients SHOULD NOT open more than one HTTP/3 connection to a given IP
address and UDP port, where the IP address and port might be derived
from a URI, a selected alternative service (ALTSVC), a configured
proxy, or name resolution of any of these.  A client MAY open
multiple HTTP/3 connections to the same IP address and UDP port using
different transport or TLS configurations but SHOULD avoid creating
multiple connections with the same configuration.
Paragraph (version A):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 9.1.2 of HTTP2.
Paragraph (version B):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 7.4 of SEMANTICS.
Paragraph (version A):
Pseudo-header fields are only valid in the context in which they are
defined.  Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT
appear in requests.  Pseudo-header fields MUST NOT appear in
trailers.  Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as malformed (malformed).
Paragraph (version A):
":scheme" is not restricted to "http" and "https" schemed URIs.  A
proxy or gateway can translate requests for non-HTTP schemes,
enabling the use of HTTP to interact with non-HTTP services.
Paragraph (version A):
The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative; see connection-reuse.
Paragraph (version B):
The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative.  If the client has not
yet validated the connection for the origin indicated by the pushed
request, it MUST perform the same verification process it would do
before sending a request for that origin on the connection; see
connection-reuse.  If this verification fails, the client MUST NOT
consider the server authoritative for that origin.
Paragraph (version B):
Requests on Stream IDs less than the Stream ID in a GOAWAY frame
from the server might have been processed; their status cannot be
known until a response is received, the stream is reset
individually, another GOAWAY is received with a lower Stream ID
than that of the request in question, or the connection
terminates.
Paragraph (version A):
A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other
streams.  On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer.  The transport
layer buffers and orders received QUIC STREAM frames, exposing the
data contained within as a reliable byte stream to the application.
Although QUIC permits out-of-order delivery within a stream, HTTP/3
does not make use of this feature.
Paragraph (version A):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on stream 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow control window.  So as to not unnecessarily limit
parallelism, at least 100 requests SHOULD be permitted at a time.
Paragraph (version B):
A pair of unidirectional streams is used rather than a single
bidirectional stream.  This allows either peer to send data as soon
as it is able.  Depending on whether 0-RTT is available on the QUIC
connection, either client or server might be able to send stream data
first.
Paragraph (version A):
An implementation MUST ignore the contents for any SETTINGS
identifier it does not understand.
Paragraph (version B):
An implementation MUST ignore any parameter with an identifier it
does not understand.
Paragraph (version B):
A large field section (request-response) can cause an implementation
to commit a large amount of state.  Header fields that are critical
for routing can appear toward the end of a header section, which
prevents streaming of the header section to its ultimate destination.
This ordering and other reasons, such as ensuring cache correctness,
mean that an endpoint likely needs to buffer the entire header
section.  Since there is no hard limit to the size of a field
section, some endpoints could be forced to commit a large amount of
available memory for header fields.
Paragraph (version B):
The CONNECT method can be used to create disproportionate load on a
proxy, since stream creation is relatively inexpensive when compared
to the creation and maintenance of a TCP connection.  Therefore, a
proxy that supports CONNECT might be more conservative in the number
of simultaneous requests it accepts.
Paragraph (version B):
A proxy might also maintain some resources for a TCP connection
beyond the closing of the stream that carries the CONNECT request,
since the outgoing TCP connection remains in the TIME_WAIT state.  To
account for this, a proxy might delay increasing the QUIC stream
limits for some time after a TCP connection terminates.
Paragraph (version B):
The use of 0-RTT with HTTP/3 creates an exposure to replay attack.
The anti-replay mitigations in HTTP-REPLAY MUST be applied when using
HTTP/3 with 0-RTT.  When applying HTTP-REPLAY to HTTP/3, references
to the TLS layer refer to the handshake performed within QUIC, while
all references to application data refer to the contents of streams.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in HTTP2, it is preferable that the assignments parallel each
other where the code spaces overlap.  If an entry is present in only
one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Settings" registry
defined in HTTP2, it is preferable that the assignments parallel each
other.  If an entry is present in only one registry, every effort
SHOULD be made to avoid assigning the corresponding value to an
unrelated operation.
Paragraph (version B):
Registrations for error codes are required to include a description
of the error code.  An expert reviewer is advised to examine new
registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated.
Use of values that are registered in the "HTTP/2 Error Code" registry
is discouraged, and expert reviewers MAY reject such registrations.