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

[Martin Thomson <[e-mail]>]

@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