Hi IETF QUIC WG’s, Is expected that clients query DNS to verify multiple origins share the same IP before reusing a QUIC connection for alternate names in the same certificate? Is that how current clients (browsers in particular) are implementing connection coalescing for HTTP/3? I am concerned about scenarios where simply looking at the certificate is not enough to confirm the server is authoritative for those domains.
The HTTP/3 specification<https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-connection-reuse> states that a client may reuse an open connection to make requests to other origins (domains) that share the same certificate. The client is not required to check if both domains resolve to the same IP as it was the requirement for HTTP/2<https://datatracker.ietf.org/doc/html/rfc7540#section-10.1>. Although the HTTP/3 document does not mention IPs or DNS resolution, it does point to the HTTP Semantics document that defines HTTP Origins in section 4.3.3<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-16#section-4.3.3>.This section does mention that “In practice, a client will make a DNS query to check that the origin's host contains the same server IP address as the established connection” Clients not following the HTTP Semantics might reuse connections in undesirables scenarios: 1. Multi Cloud Provider or CDN: CDN customers might split properties across cloud provides or perform migrations between them. It is possible for an origin owner to provision a certificate with multiple domain names that have not being completely migrated to the cloud provider. In those cases the cloud provider will have no configuration settings and will not know how to handle the request for the domains that have not been migrated. It is also possible that one cloud provider have not being updated with the latest set of changes (e.g. using cloud providers in a blue/green development strategy and using DNS to release code). 2. Different Security Postures: domain owner might point compliant traffic (PCI/HIPAA) to different server IPs than non-secure traffic in an effort to reduce CAPEX/OPEX related to compliance requirements. A bank, for example, could have a secure service with a single domain certificate for secure.bank.com. Marketing websites could be on a less protected infrastructure using a wildcard.bank.com. Connections open to a marketing website could result on coalescing to www.bank.com<http://www.bank.com>; thus, resulting on compliant traffic in a not-so-compliant environment. The Origin frame<https://datatracker.ietf.org/doc/html/rfc8336> would be a great resource for the server to retain some control over coalescing, but it is not supported on HTTP/3 yet. The reason of my question is that it is confusing (at least for me) that the specification expects developers to understand which document takes priority. I am curious on how people are implementing HTTP/3 connection reuse so I could get a better idea on how likely is for the scenarios mentioned above to occur. Regards, Manuel Alvarez Product Architect Akamai Technologies
