Parameter to indicate no HSTS-like behavior?

[enygren]

In digging into production use-cases, there may be scenarios where the "HTTPSSVC means HTTPS-only" is problematic. For example, it may prevent a CDN from turning it on by default (as this means forcing everything to HTTPS-by-default which may not be possible for some customer content) which in-turns prevents turning on Encrypted SNI by default.

Leaving the HSTS-like behavior as the default makes sense, but this asks the question as to whether an optional "allow-insecure" parameter should be included (with the default still being secure). This opens up cans of worms from a security perspective but could ease deployment in some cases.

[bemasc]

I think I understand the problem. If a CDN has N customers who have CNAMEd their domains to a CDN domain, and some of those customers are using insecure HTTP and haven't provided the CDN with TLS certificates, then the CDN can't put HTTPSSVC on the domain. They would have to create a new, HTTPS-only domain, and ask customers to update their CNAME.

Technically, the CDN could acquire DV certs for all the customer domains, and upgrade them to HTTPS (at least between the client and CDN), but this could cause problems related to mixed-content blocking, if some of those customer domains load third-party insecure content that isn't hosted on the same CDN.

I think I would call this parameter "disable-https-upgrade", and continue to prohibit the "_http" prefix.

[davidben]

Such a CDN would then cause all N customers to go through the allow-insecure path, right? That means the customers who don't update their CNAME would inadvertently get a less secure configuration, so one would still want everyone to update CNAMEs, but now with decreased incentive (but correspondingly more adoption of other bits of HTTPSSVC, so it's a tradeoff between adoption and getting the ecosystem in a better place).

[davidben]

Given that it is 2020 and HTTPS is table stakes, I'm inclined to think this would not be the right tradeoff.

[bemasc]

Possible compromise: disable-https-upgrade only applies if echconfig is also present. This is extremely hacky and I'm not sure I really like it, but it would ensure that this is only used in cases where HTTPSSVC is actually providing some benefit to someone.

[martinthomson]

What David said. I don't see any point in continuing to cater to unsecured protocols.

In the earlier example Ben provided, the CNAME that the mix of secure and insecure customers refer to doesn't need to be singular. You don't need new servers, just a separate CNAME target. That seems entirely workable.

[tfpauly]

Agreed. If you want a bad mix of security, that's your burden for deployment.