disable-https-upgrade SvcParamKey #164
Conversation
Fixes #100 Will want working group discussion before merging. (End resolution may be to reject this.)
There was a problem hiding this comment.
How strongly is there a need for such a key? It seems a bit odd to define the key and then strongly discourage it. If anything, it should be marked as SHOULD NOT use or support, which seems tenuous.
If deployments need something like this in the future, I’d prefer to see it as an extension.
| @@ -1207,6 +1218,11 @@ network, or flushed on network changes, to prevent a local adversary in one | |||
| network from implanting a forged DNS record that allows them to | |||
| track users or hinder their connections after they leave that network. | |||
|
|
|||
| The use of "disable-https-upgrade" is strongly discouraged. | |||
| It exists only to allow multi-tennt server operators to deploy {{ECH}} | |||
I agree: it's odd, at best. The argument in favor is: imagine 10 million domains are CNAMEd to cdn.example.net, and 1% of them don't support HTTPS. Currently, that means example.net can't deploy ECH for the other 99%. Instead, they have to create cdn2.example.net, with HTTPSSVC, and convince them all to update their CNAMEs. I'm not sure how to feel about this problem.
Unfortunately, this can't easily be done as a future extension, because, in the situation where it's needed, it only works if all clients support it. Since clients ignore unrecognized SvcParamKeys, that means older clients would continue to enforce HSTS, thus breaking all the non-HTTPS domains. |
|
I see the incentive of getting everything on a given CNAME supporting TLS at the same time as a positive thing. Isn't it still possible in a deployment to choose to separate out CNAMEs differently if you need only some to support ECH? That way, the burden of disabling uniform encryption is placed upon the server DNS deployment, not on the clients that now need to write codepaths to pass up ECH keys but also consider that the connection may not support TLS. It feels like we should make things easy to be secure, but not optimize for cases that are insecure and should long-term be fixed. |
But don't the 99% then lose the upgrade behavior? I'd call that much worse than forcing the last 1% to upgrade (or for them to switch to cdn2.example.net to keep working). Overall, I'm not a fan of disabling the upgrade, even with the newer "compromise" of only supporting it with ECH. It's overall a good thing if HTTPSSVC and ECH force more HTTPS usage, and it seems a reasonable requirement in 2020. The ECH-only part just adds an unnecessary (and kinda weird) complication that I'd really rather not support. |
|
This comes down to the ability to make a risk/reward business case for enabling ECH for existing shared domains. With this capability there may be a chance to make a business case from a risk/effort trade-off. Without this capability I don't see those large shared domains ever getting ECH enabled. ie, who is going to care enough and push hard enough to force taking the risk of breaking sites or risk making customers unhappy? I could see CDNs with "free tiers" just enabling ECH for shared domains, but the risk/reward and business drivers may not exist yet in the commercial space. It may be a reasonable decision to decide not to do this from a complexity perspective, but with the understanding that we should not then expect default ECH enablement for existing sites in some of the environments that would most benefit. |
|
Getting HTTPSSVC on those domains is still a benefit for load balancing, HTTP/3 deployment, and the HTTPS upgrade, no? And any risks around ECH itself would be there regardless. This would make sense if moving to another CNAME to weather the HTTPS upgrade was the limiting factor against a hosting provider offering ECH by default. Is that really the case here? |
|
It's not just an issue of moving CNAMEs. The issue is that some "bulk" CDN configurations have a mixture of HTTP-only, HTTPS-only, and HTTP+HTTPS mixed hostnames. There's not always a clear differentiator between these, so enabling HSTS-style behavior must be opt-in which then precludes enabling ECH in anything other than an opt-in manner. |
|
+1 to using the proposal in #166 to address this as an extension. |
|
Does that (or this PR, for that matter) actually disable the upgrade? #156 says you redirect to HTTPS on the mere presence of the HTTPS record, without following alias forms or anything. |
|
Presumably, a client that has to discard the entire RR would not interpret it as being "present"? |
|
If it needs to follow an alias form to find the critical extension, it won't notice. |
|
Presumably at that point (if it just followed the Alias) and found the effectively-empty HTTPS RRset and A/AAAA records then it would just use the A/AAAA records. |
|
If we had support for mandatory=, then that would allow clients to not implement disable-https-upgrade but for servers to specify that records are only available to clients implementing support which might make it safe to include here? |
|
The behavior is that it doesn't follow the alias form records. That the second DNS query might hit A/AAAA records and miss the service form is exactly why the redirect should fire without following. |
|
disable-https-upgrade can't be present on an Alias form record. |
|
We need to put together DNS Records that can be used to validate correct/incorrect behavior. |
Be extra clear that disable-https-upgrade only applies to Service Form. (This may be somewhat redundant but is worth being crystal clear on to avoid confusion.)
|
Ah okay, I think I misunderstood you. Yeah, if the expectation is that alias form precludes disabling the upgrade, #156 is consistent with all this. Though I still maintain that, as it's 2020, this is silly. :-) |
|
Now that we have "mandatory" (#166), I think we should postpone this design to a separate document. |
|
Deferring to a potential future draft based on need. |
Fixes #100
Will want working group discussion before merging.
(End resolution may be to reject this.)