Subject: HTTP/3 Connection Reuse (Coalescing) Implementation

From: "Alvarez, Manuel" <[email-masked]>
Date: Thu, 12 Aug 2021 18:48:05 +0000

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

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 13 Aug 2021 09:18:08 -0700

On Fri, Aug 13, 2021 at 8:32 AM Alvarez, Manuel <maalvare=
[email-masked]> wrote:

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

Chrome's HTTP/3 connection coalescing / reuse implementation matches
Chrome's HTTP/2 implementation and requires IP address overlap. Hope that
helps!

Cheers,

Ryan

---

From: Dragana Damjanovic <[email-masked]>
Date: Sat, 14 Aug 2021 00:12:04 +0200

> Chrome's HTTP/2 implementation and requires IP address overlap. Hope that
At the moment, Firefox coalescing behavior for HTTP/3 is the same as
Firefox's HTTP/2 coalescing behavior.

dragana

---

From: "Alvarez, Manuel" <[email-masked]>
Date: Fri, 13 Aug 2021 21:21:49 +0000

Thank you Ryan,

It does help. I wonder how other browsers will implement it though.

Manuel Alvarez

From: Ryan Hamilton <rch=[email-masked]>
Date: Friday, August 13, 2021 at 12:18 PM
To: Manuel Alvarez <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: HTTP/3 Connection Reuse (Coalescing) Implementation

On Fri, Aug 13, 2021 at 8:32 AM Alvarez, Manuel <maalvare=[email-masked]<mailto:[email-masked]>> wrote:
<snip>
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.

Chrome's HTTP/3 connection coalescing / reuse implementation matches Chrome's HTTP/2 implementation and requires IP address overlap. Hope that helps!

Cheers,

Ryan

---

From: Eric Kinnear <[email-masked]>
Date: Mon, 23 Aug 2021 18:45:12 -0400

> On Aug 13, 2021, at 6:12 PM, Dragana Damjanovic <[email-masked]> wrote:
> 
> 
> 
> On Fri, Aug 13, 2021 at 6:18 PM Ryan Hamilton <rch=[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Aug 13, 2021 at 8:32 AM Alvarez, Manuel <maalvare=[email-masked] <mailto:[email-masked]>> wrote:
> <snip> 
> 
> At the moment, Firefox coalescing behavior for HTTP/3 is the same as Firefox's HTTP/2 coalescing behavior.

Safari’s coalescing implementation for HTTP/3 is currently the same as it is for HTTP/2, and it requires IP address overlap.

Thanks,
Eric