Benjamin Kaduk's Discuss on draft-ietf-quic-http-33: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-quic-http-33: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-http/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[note to Lucas/chairs: a few (three, I think) of these discusses/comments
have preexisting github issues created by the editors over the past couple days
due to some out of band discussions; if we can easily reuse them instead of
creating new ones that would be preferred]

(discuss point 1)
Mike already filed https://github.com/quicwg/base-drafts/issues/4761
and I think we can keep the discussion there.
But to reiterate, we reference [SEMANTICS] for certificate validation
and use in determining authority for the "https" scheme, yet the
additional prose discussion we offer (with CN-ID and DNS-ID as the
certificate fields to validate against, though not by that name) does
not match what's currently present in [SEMANTICS].  Discussion so far on
the linked issue against [SEMANTICS] suggests that [SEMANTICS] will
change, but we should not go forward with this document until we've
resolved the disparity.  (One might also wonder whether we need to
duplicate the content ourselves or should just reference the other
document(s).)

There is a related topic in that our current formulation in this
document treats CN-ID and DNS-ID as equivalently recommended, but
current recommendations (including in RFC 6125) are to prefer SAN-based
names over the (legacy) CN-ID.  I believe there are even some efforts
underway in the Web ecosystem to move to fully deprecating the use of
CN-ID; at present I believe that some entities require that any name
present in the CN-ID be replicated as a DNS-ID as well.  If we are to
proceed with giving equal preference to CN-ID and DNS-ID, I think that
we need to justify or at least call out the divergence from current IETF
guidance.
[Martin filed https://github.com/quicwg/base-drafts/issues/4769 for
the topic regarding whether CN-ID is mandatory or even recommended.]


(discuss point 2)
I also think that the procedure, as written, for coalescing HTTP
requests against different URI authority components onto a single HTTP/3
connection is under-specified and seems inconsistent both with earlier
WG conclusions and with previous IETF-mandated practices for certificate
validation.

[begin historical tracethrough]
There appears to be quite a long history in this space (and I probably
missed some of it, even).  The idea of coalescing has been around back
from the days when we only allowed Alt-Svc as discovery for using QUIC
(no direct access), with
https://github.com/quicwg/base-drafts/issues/940 being an early issue
leading to https://github.com/quicwg/base-drafts/pull/1024/files, with
text that requires both Alt-Svc and valid certificate in order to be
authoritative.  Then we had
https://github.com/quicwg/base-drafts/issues/2223 that notes that this
Alt-Svc requirement is more restrictive than RFC 7540, which allegedly
only requires the certificate to match a given name.  (One might argue
that 7540's "additionally depends on having a certificate that is valid"
implies the "depends on the host having resolved to the same IP address"
still applies, though of course ORIGIN weakens that if it was ever
present and this is not terribly relevant to the current question.)
Comments on #2223 seem to confirm that the intent is to largely parallel
what HTTP/2 does; I'll come back to that in a bit.  The corresponding
text changes here are
https://github.com/quicwg/base-drafts/pull/3558/files that brings in the
concept that "a server is considered authoritative for all URIs with the
'https' scheme for which the hostname in the URI is present in the
authenticated certificate provided by the server, either as [...]".
This text got moved a bit and reworded slightly in response to the
secdir review (https://github.com/quicwg/base-drafts/pull/4419/files),
but the intent is largely still present as "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."
[end historical tracethrough]

So now we have text that says:

   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.

This seems problematic to me, and divergent from HTTP/2, in that it
focuses on the contents of a certificate *all* being valid/authoritative,
as opposed to a certificate being valid for a given host/name.  To quote
§9.1.1 of RFC 7540:

   For "https" resources, connection reuse additionally depends on
   having a certificate that is valid for the host in the URI.  The
   certificate presented by the server MUST satisfy any checks that the
   client would perform when forming a new TLS connection for the host
   in the URI.

A representative discussion of these checks is included in RFC 6125, and
the general procedure for (server) certificate validation takes as input a
candidate name of a service or entity that the client is attempting to
contact, a certificate (chain) and signature presented by the server,
and the application context in which the decision is being made [0].  In
short, the question is always "do I (as the client) trust the peer
entity to act as this specific name?", and the answer may differ across
names present in a single certificate!  So I think we need to refresh
this text once more, to bring back the sense that for each name that we
might want to allow the server to act as an authority for, we have to do
the normal validation checks.  Saying that we validate a certificate
once along with proof of possession of its private key and then the
holder of the key is a valid authority for all names in the certificate
invites violation of the client's security policy.  For example, the
client's trust database might not allow the CA(s) in the presented chain
to certify some of the names contained in the certificate, among other
reasons.

(discuss point 2.1)
There is probably some extra excitement surrounding revocation, in that
the "normal certificate validation procedures" typically involve some form
of attempt at a revocation check.  What should happen if this check
determines that the certificate has been revoked is not entirely clear.
Presumably the attempt to use a new name from the certificate would
fail, but does it also imply that the entire connection should be torn
down, since it was built using the now-revoked certificate?

(discuss point 2.2)
In practice, the procedure of "check the name in question against the
certificate chain" seems to mean that a client that is willing to
coalesce connections needs to retain the certificate and chain presented
by the peer, so that it is available as input to the certificate
validation engine (typically accessed via the TLS stack, I suppose) at
the time when an authentication decision needs to be made for a given
name.  This operational practice, as well as the actual mechanics of
running a fresh certificate validation procedure, should probably be
mentioned down in Section 3.3 where we discuss the actual connection reuse
procedures.  In particular, I think it would be very benficial to
indicate what protocol interactions trigger an attempt by the client to
validate a new name from the certificate for use as the authority for
HTTP responses, as well as to note clearly that the certificate+chain
have to be retained in order to run these checks.

(discuss point 2.3)
I think we should also look at the procedures for server push as they
relate to coalescing; my understanding is that pushed responses are
allowed to be for requests to a different authority, and thus that a
client will need to discard or reject pushes that are from an authority
that the client does not accept the peer as being authoritative for.  I
guess this is in some sense a check that the client always has to do for
all pushed responses, but I'm not entirely sure whether or where that is
currently described.

[0] This context includes things like the set of trust anchors, as well
as potentially information about restrictions on trust anchors,
revocation checks, pinning or other restrictive information that reduces
the set of CAs that might be allowed to certify a given name, etc.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for another clear and well-written document.  I especially
appreciated Appendix A.


Thanks to Hilarie Orman for the secdir review and to the team for
responding to it!  It looks like one of the secdir review comments
didn't get its own github issue, so perhaps we can discuss it now:

> I would like to see the Security Considerations spell out exactly
> what security features HTTP expects from QUIC.

Perhaps we could add a line to Section 1.2 where we discuss how QUIC
provides comparable confidentiality and integrity to TLS+TCP, along the
lines of "HTTP/3 relies on QUIC to provide that confidentiality and
integrity protection of data, as well as to provide peer authentication
and reliable, in-order, per-stream delivery."


With all HTTP/3 frames being sent on QUIC streams, including
connection-wide control frames on the control stream, we are in the
situation where QUIC flow control can prevent the conveyance of HTTP
control messages.  This is in some sense covered in Appendix A.2.3,
since "all HTTP/3 frame types defined in this document are sent on
streams", but the corresponding PR discussion seems to have mostly
focused on how this applies to request/response headers, and while the
discussion in #204 does confirm that it is intentional for flow control
to apply, that doesn't really cover whether it is worth noting as a
potentially surprising difference from HTTP/2.  While the HTTP frames
currently defined for the control stream might not be too catastrophic
to be blocked from sending (assuming that SETTINGS will typically get
through in the initial window), I do still wonder if giving specific
guidance on flow control for the HTTP control stream could be useful.
(E.g., calling out that an endpoint might terminate the connection if
blocked by flow control on the control stream for an extended duration,
or even requiring preferential treatment for window updates.)

Section 4.1.1

  Such intermediaries
   SHOULD also remove other connection-specific fields, such as Keep-
   Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they
   are not nominated by the Connection field.

I don't understand why Transfer-Encoding is intrinsically
connection-scoped.  [HTTP11] seems to discuss it acting on a "message"
and being tied to a specific request or response.

Section 9

Is there anything useful to say about whether an HTTP extension might
want to make use of QUIC frames other than STREAM?  In the spirit of
greasing, I worry that if we don't say something, "all HTTP/3 frames go
in QUIC STREAM frames" might become an implicit invariant.  (Yes, I know
about draft-ietf-quic-datagram.)

Section 10.5.2

There is some good discussion in [HTTP-SEMANTICS] about the risk of
CONNECT being used as an arbitrary tunnel, that is probably worth
referencing from here.

   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.  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.  Therefore, a proxy
   cannot rely on QUIC stream limits alone to control the resources
   consumed by CONNECT requests.

I'm not sure how well this last sentence translates from HTTP/2 to
HTTP/3 -- in HTTP/2 the limit is on the number of concurrent streams,
but QUIC gives a hard cap on the absolute stream number, so IIUC an
endpoint could refuse to allow new streams until TCP state had quiesced.
(Of course, this would also prevent any new HTTP requests from being
sent...)

Section 10.9

I think it might be worth another sentence to reiterate that when
[HTTP-REPLAY] talks about "the TLS layer", this applies to the TLS
handshake layer as used as part of QUIC v1, and when it talks about
"early data" that means QUIC 0-RTT.  FWIW, I made a quick pass through
RFC 8470 to look for references to TLS, and didn't find any references
to TLS that would not also apply to QUIC v1's usage of TLS.  (It does
have things like "early data received on that TLS connection" that do
not strictly speaking apply to HTTP/3, but I don't see that one as
particularly problematic.)

Section 11.2.1, 11.2.2

We give the HTTP/3 experts (and registrants) some guidance that
coordinating with the HTTP/2 registries is useful.  Do we want to add a
note to or otherwise update the guidance for the HTTP/2 registries to
give analogous advice to the HTTP/2 experts?

[Mike already opened https://github.com/quicwg/base-drafts/issues/4760
based on some out-of-band discussion, which I incorporate here by reference.
Summary: We probably want the DEs to be able to reject requests to stomp
on a value already used in the other protocol, in addition to the first
unassigned value and excessive/bulk requests.]

Section 11.2.2

I note that RFC 7540 marked setting code 0x0 reserved for h2; should we
mirror that?

Section 12.1

[ALTSVC] doesn't exactly seem to be referenced in a normative manner
anymore.  Back when it was the only way to do HTTP/3 it made sense, but
the current description seems mostly to be saying that "other services
could use Alt-Svc to initiate HTTP/3" which is arguably not really
something you have to know in order to implement and use this spec.

Section 12.2

Can we review the places that reference [HTTP11]?  It seems like we may
be deferring to it for the semantics of, e.g., CONNECT, and OPTIONS with
asterisk-form authority, which would seem to make it a normative
reference, which I understand to be something we're trying to avoid.

Appendix A.3

(nit) I note that A.2.5 gave the codepoints for the HTTP/2 frame types being
discussed; should do the analogous thing for HTTP/2 settings types?