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

From: Lucas Pardue <[email-masked]>
Date: Wed, 20 Jan 2021 11:37:33 -0800

@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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Jan 2021 14:45:37 -0800

I think that the main concern here is addressed by a change - or addition - to the text that Ben 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.

-- 
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#issuecomment-764002408

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Jan 2021 03:31:14 -0800

Labeling as design, since #4808 is.

-- 
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#issuecomment-767483239

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Jan 2021 00:06:06 +0000 (UTC)

Closed #4775 via #4808.

-- 
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#event-4253295750

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jan 2021 16:07:19 -0800

Reopened #4775.

-- 
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#event-4253299496

---

From: Mike Bishop <[email-masked]>
Date: Wed, 27 Jan 2021 00:07:19 +0000 (UTC)

Reopening for consensus call.

-- 
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#issuecomment-767912747