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

From: HTTP issue updates <[email-masked]>
Date: Sat, 08 Jul 2017 02:21:12 +0000 (UTC)

> 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

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 09 Jul 2017 05:41:52 +0000 (UTC)

@PiotrSikora - thanks for the input.

WRT global load balancing / CDN balancing -- one of the things that has been discussed is a bit to tell the client whether or not to check DNS; that would allow them to use this, I think.

WRT wildcards -- ORIGIN doesn't currently support wildcarding.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 10 Jul 2017 21:58:07 +0000 (UTC)

Even without supporting wildcard ORIGINs, @PiotrSikora has a valid point that if a server has a wildcard cert it can pull in any hostnames that it wants to.

Telling a client whether or not to check DNS certainly helps for some of these cases (ie, it helps avoid a few operational snafus) but doesn't help against malicious use-cases.

My inclination is still to pull this draft back to the original "limiting origin set and connection reuse" scenario but while leaving placeholders for a subsequent draft that would cover expanding the origin set (ie, with using additional-certs and whatever other mitigators are deemed appropriate).  Otherwise this draft changes the operational model of the web much more substantially than people may realize at first glance.  Any operational shift this significant likely wants to be a first-class discussion rather than being a side-effect of a draft that initially had a much more constrained scope.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 10 Jul 2017 15:31:41 -0700

wrt "check DNS" flag - it's still the server (i.e. CDN) that's making this recommendation to the client, right? If so, then I don't think it fixes anything, since CDNs can omit this flag and prevent clients from consulting DNS, justifying this with "we're improving the performance" excuse.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 10 Jul 2017 17:11:36 -0700

Let me try to summarize the concern in a different way: having a certificate for a name is not always sufficient basis for that server to be chosen and used.

All these cases reduce down to the same complaint: the client might be talking to an instance that has a certificate for N>1 names and the intent is that only a subset of those names is used.  This might be due to geographical distribution of nodes, contractual arrangements (the CDN is charging more than their competitor today, so they're on backup duty), or any other operational concern.

The problem with all of these is that there is no way to communicate this intent to the client that doesn't ultimately chain back to the certificate.  A certificate that the server instance has.  Relying on the DNS is a fig leaf.  As @PiotrSikora says, even DNSSEC fails because you can't be sure that this is the RRset that would be sent to *this* particular client.

It looks like what you are looking for is a better means of control over your server instances.  The reliance on DNS is a poor substitute for a genuine signal.

Crazy suggestion, would a certificate extension that enabled this functionality make you happier?  As long as the CDN never received a certificate with the extension, it couldn't make these sorts of assertions.  I'm not saying that I think that's a good idea, but I want to explore the boundaries of your problem better.

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

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 16 Jul 2017 03:11:59 -0700

@martinthomson I originally wanted to dismiss this idea (since CDNs could mis-issue certs with the extension anyway, so it doesn't add 2nd factor). However, we chatted a bit about it with @grittygrease yesterday, and we came to conclusion that opt-in certificate extension, along with CT requirement (so that it would be obvious that CDN requested certificate with such extension, even when domain owner didn't opt-in for it) seems like an acceptable solution.

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

---

From: HTTP issue updates <[email-masked]>
Date: Sun, 30 Jul 2017 21:05:24 -0700

Please review proposed changes in latest commit.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 31 Jul 2017 16:32:29 -0700

I see the associated suggestions in the Security Considerations, but I thought the discussion on the list led toward putting a "MAY skip, but SHOULD use something else instead"?  Even if the concrete suggestions of what the "something else" could be still live in Security Considerations....

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 31 Jul 2017 16:35:44 -0700

I don't see how I can put "SHOULD use something else" in an RFC with a straight face. If someone can suggest appropriate wording here, I'd be ever so grateful. 

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 31 Jul 2017 16:39:55 -0700

On the thread, "Clients opting not to check DNS SHOULD employ some alternative means to increase confidence that the certificate is legitimate, such as Certificate Transparency or revocation checks" got +1s from Ryan and @enygren.  Since you have a mention elsewhere, you could adapt that to "such as those discussed in Section 4" reasonably enough.

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

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 31 Jul 2017 16:52:33 -0700

Hmm. I suspect a requirement that's so vague won't get through IESG, but I guess we can try it.

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