[quicwg/base-drafts] Ben Kaduk's HTTP/3 Discuss 2 (#4775)

[Lucas Pardue <[e-mail]>]

@kaduk said

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4775