Subject: [quicwg/base-drafts] Rework HTTP authority/coalescing again (#4808)

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Jan 2021 08:22:42 -0800

While the changes to SEMANTICS are still in flight, that doesn&#39;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 @kaduk and @rdanyliw.

Fixes #4761.
Fixes #4763.
Fixes #4764.
Fixes #4775.

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 https://github.com/httpwg/http-core/pull/685)
- Require clients to re-perform validation for each new origin
    - ...noting 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
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4808

-- Commit Summary --

  * Refer to SEMANTICS for validation procedure
  * Expand reuse discussion
  * 421 in Semantics
  * Expand push equivalence to connection reuse

-- File Changes --

    M draft-ietf-quic-http.md (54)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4808.patch
https://github.com/quicwg/base-drafts/pull/4808.diff

-- 
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/pull/4808

---

From: Martin Thomson <[email-masked]>
Date: Sun, 24 Jan 2021 23:11:47 -0800

@martinthomson commented on this pull request.

Some suggestions.  I think that the certificate retention bit needs a tweak.

> -component of the URL.
-
-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.
-
-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.
+component of the URL.  Upon receiving a server certificate in the TLS handshake,

URI?

> +4.3.4 of {{!SEMANTICS}}.  This implies that clients will need to retain the
+server certificate chain; clients which do not do so will be unable to reuse the

I think that this needs to say that it retains the certificate and any information it might need for validation of that certificate (this implies a need for extra information that includes intermediate certificates, CT SCTs, stapled OCSP, and other details the client might depend on).

> -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.
+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 chain; clients which do not do so will be unable to reuse the
+connection for additional origins.
+
+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.

This might need a "for instance", which might be "For instance, if validation of the certificate fails because the certificate expired, then this might be used to invalidate all other origins for which that certificate was used to establish authority."

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

I know that this is old, but the discontinuity here is jarring.  S1 uses "host and port", S2 uses "IP and port".  I think that the first can be made IP/port, noting that the IP and maybe port is obtained through name resolution, proxy configuration, or alternative services (which might include name resolution).

-- 
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/pull/4808#pullrequestreview-575107959

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Jan 2021 09:20:07 -0800

@MikeBishop commented on this pull request.

-

```suggestion
component of the URI.  Upon receiving a server certificate in the TLS handshake,
```
Yes.

-- 
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/pull/4808#discussion_r563899515

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Jan 2021 09:23:02 -0800

-

#4812, but no harm fixing it here, too.

-- 
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/pull/4808#discussion_r563901680

---

From: Mike Bishop <[email-masked]>
Date: Mon, 25 Jan 2021 09:27:58 -0800

@MikeBishop pushed 1 commit.

31a9f12a9b125f5ce0eaee03d9960ff69ead8163  Martin's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4808/files/8b12ead95c23d295c06a855f7ba69903fe26ca6b..31a9f12a9b125f5ce0eaee03d9960ff69ead8163

---

From: kaduk <[email-masked]>
Date: Mon, 25 Jan 2021 20:23:39 -0800

@kaduk approved this pull request.

This is good; thank you.
The minor inline comment might also be addressed in [SEMANTICS] instead of here, I think.

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

This seems to be the only place that we clearly state that failed verification implies not authoritative.  [SEMANTICS] does talk about attributing authority to a  server based on certificate validation, but in 4.3.3, not 4.3.4.
What we say for "normal" re-use seems to be okay without such a (re)statement, since we just say "don't reuse; open a new connection" which would get us back to the procedures here.  But for server-push we might want to reiterate that failed verification means not authoritative (and then we fall through to the subsequent paragraph for "SHOULD send CANCEL_PUSH" for non-authoritative pushes).

-- 
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/pull/4808#pullrequestreview-576000242

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jan 2021 11:34:44 -0800

@MikeBishop pushed 2 commits.

041fd43fdf984ceafe336abff23ae34da50a19fc  Failed verification == no good
f9d47199dd9d9a16154117694e680981f5160881  Merge remote-tracking branch 'origin/master' into http/authority_again

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4808/files/31a9f12a9b125f5ce0eaee03d9960ff69ead8163..f9d47199dd9d9a16154117694e680981f5160881

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jan 2021 11:35:21 -0800

Added in 041fd43f.

-- 
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/pull/4808#discussion_r564779089

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jan 2021 15:38:55 -0800

@martinthomson approved this pull request.

-- 
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/pull/4808#pullrequestreview-576857526

---

From: kaduk <[email-masked]>
Date: Tue, 26 Jan 2021 16:03:40 -0800

-- 
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/pull/4808#pullrequestreview-576868374

---

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

Merged #4808 into master.

-- 
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/pull/4808#event-4253295723