Re: [httpwg/http-extensions] Consulting the DNS on expanding ORIGIN set? (#330)

[HTTP issue updates <[e-mail]>]

> I'm trying to understand your second concern WRT operational behavior of clients. The origins being added are explicitly nominated by the server; presence in the certificate is not enough to cause the connection to be used (indeed, that concern was a large part of the motivation of this draft).

I believe that limiting origin-set and connection reuse was the original motivation for this draft, however, it seems that possible use cases changed a bit because of [draft-bishop-httpbis-http2-additional-certs](https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-http2-additional-certs), which together with this draft, makes it possible to expand the origin-set and effectively hijack traffic for all domains that server has valid SSL certificates for.

Even ignoring the compromised server scenario, there are at least a few operational issues with bypassing DNS:

1. Many medium to large companies use multiple CDN providers and steer traffic using DNS. They use either custom GeoDNS solutions or services like [Cedexis](https://www.cedexis.com/solutions/multi-cdn/) to load balance traffic across multiple CDNs, or simply use one of the CDNs as the primary and rest as active backups. All those CDNs have valid SSL certificates, so neither CT nor certificate pinning would help.
Similarly, some websites migrate traffic to DDoS protection services only during attacks, but those services are configured and have valid SSL certificates at all times.
**Basically, configured != active.**

2. Servers with wildcard certificates can takeover all traffic for the domain, even if some subdomains would never be routed to a particular server. To give an extreme example, let's say that `www.bank.com`, `promotions.bank.com`, etc. are served by the CDN, but `secure.bank.com` is handled by the bank's own infrastructure. There is nothing stopping the CDN with valid certificate for `*.bank.com` from hijacking the traffic for `secure.bank.com`, and while certificate pinning would prevent traffic for `secure.bank.com` from reaching the CDN, it would effectively result in DoS and pretty bad end-user experience.

One solution that came up in discussions with @grittygrease and @enygren, was to include signed DNSSEC response in the `ORIGIN` frame, to prove that the traffic should be routed to this particular server. This obviously solves only part of the problem, since it doesn't mean that traffic from _this particular client_ would be routed to that server, but it's much better than servers going completely wild.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/330#issuecomment-313827663