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

[Lucas Pardue <[e-mail]>]

Hi Ben,

Thanks for the review. I've created GitHub issue(s) to track each comment
on the QUIC WG repository, see the URL(s) in line.

Where there was already an issue, I've edited the description to include
the logical number that it would have appeared. This is mainly a cosmetic
touch to avoid us later pondering why the sequence contained gaps etc.

Apologies to Hilarie Orman for missing an item in the secdir review, this
would have been due to some accident or mistake. We've attempted to respond
to any and all review comments, so let's get this one addressed now. Thanks
for the patience.



On Wed, Jan 20, 2021 at 6:30 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> 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.]
>

No new issue create, the URL remains
https://github.com/quicwg/base-drafts/issues/4761


>
> (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.
>

I've collected all of the these discuss points on
https://github.com/quicwg/base-drafts/issues/4775


>
> ----------------------------------------------------------------------
> 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."
>

https://github.com/quicwg/base-drafts/issues/4776


>
> 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.)
>

https://github.com/quicwg/base-drafts/issues/4777


> 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.
>

https://github.com/quicwg/base-drafts/issues/4778


> 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.)
>

https://github.com/quicwg/base-drafts/issues/4779


> 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...)
>

https://github.com/quicwg/base-drafts/issues/4780


> 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.)
>

https://github.com/quicwg/base-drafts/issues/4781


> 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.]
>

No new issue, https://github.com/quicwg/base-drafts/issues/4760 still
applies

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

https://github.com/quicwg/base-drafts/issues/4782

>
> 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.
>

https://github.com/quicwg/base-drafts/issues/4783


> 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.
>

https://github.com/quicwg/base-drafts/issues/4784


> 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?
>

https://github.com/quicwg/base-drafts/issues/4785

Cheers
Lucas
On behalf of QUIC WG Chairs