-
Notifications
You must be signed in to change notification settings - Fork 19
FAQ
Why this and not that?
We originally proposed XML to hew closely to DMARC. Upon feedback from IETF, however, we switched to JSON (which, in particular, aligns nicely with CSP and HPKP reporting).
We could simply always fetch https://example.com/.well-known/sts-policy to determine if a policy exists. If we do so, however, we would run into two problems:
- Repeatedly fetching a non-existent URI for domains that have no STS policy.
- Repeatedly fetching a failing policy on delivery failures. Since we specify senders to check for a new policy in the case of policy failures ("Policy Application" in the draft), every policy failure would, in a naive implementation, result in a new policy fetch.
In these two cases, the HTTPS endpoint (if any) would have to handle one-query per SMTP delivery. Domains with a small HTTPS presence may not be able to handle this traffic.
The obvious solution to this is to provide some sort of "TTL" on the policy, so that senders can (in cases #1 or #2 above) cheaply check for the existence of a policy and whether it has been refreshed. #2 is addressable by adding a TTL to the STS policy itself, but #1 is not. Fortunately, DNS has exactly this property, including for NXDOMAIN responses, and is thus ideal for this case.
So tl;dr: DNS is used to transmit a) STS policy existence and b) STS policy currency.
We have considered three use-cases for ‘example.com’ to host its policy:
- The policy is always at https://example.com/.well-known/sts-policy (i.e. top-level domain with URI path)
- The policy is always at https://sts_policy.example.com/current (i.e. 2nd-level subdomain)
- The policy is always at https://policy.sts.example.com/current (i.e. a 3rd-level subdomain)
There are two considerations here: a. Making it easy for domains to host the policy, even if their primary ("naked domain") HTTP/S presence goes somewhere outside of their control. b. Ensuring that domains who allow untrusted users to control hosts or subdomains are not put at risk. For example, tumblr.com or dyndns.org allow untrusted users to register arbitrary subdomains; could a user register "sts_policy.dyndns.org" and thus serve a valid (and potentailly DoS-inducing) policies.
The risk in (b) is of turning a transient DNS-injection DoS into a long-lived DoS due to policy caching. However, note that this is only possible in the case where the attacker can also serve HTTPS traffic with a cert for example.com. Moreover, if an attacker can do this, the specifics of DNS policy may not matter much; since the attack already presupposes attacker-controlled DNS responses, we can assume an attacker can inject a new A record for "example.com."
There is, however, one specific case where the DNS policy may matter, and this is the case where the policy domain serves untrusted content over HTTPS, does so as a "virtual host" using the HTTP/1.1 Host header, and allows users to register "sts_policy.example.com." In this case, the attacker can get around the CA cert restriction but, even with attacker-controlled DNS, the attack depends on the sending domain fetching the policy from "sts_policy.example.com."
Whew!
This has two problems:
- It requires SMTP servers to support STS, which raises the bar for initial "report-only" deployments. Presently, the recipient need never modify their SMTP server, and the sender can do a "report-only" deployment without modifying their SMTP server (as long as it logs sufficient data--DANE or WebPKI certificate validity and TLS status--for later analysis).
- It presents problems for policy revocation in the case where a user migrates to an MTA that cannot serve policies.
Issue #2 is a subtle issue, but a critical one for users of hosted mail services. In the case where customer.com is hosted at stshost.com and wishes to use STS, stshost.com can serve an STS policy during SMTP exchanges. But if customer.com then migrates their hosting to nonstshost.com, they have no mechanism to serve the "do not enforce" policy (effectively revoking their earlier policy) because their new host doesn't support STS to begin with! Thus the only safe way for them to migrate is to stop serving a policy and wait until their last-served policy expires! This kind of customer lock-in seems unacceptable to us, though others have suggested that migrating to a host with lesser security should be made difficult.
There are a lot of considerations here, but a few points:
- Providers will probably wish to define the policy for their customers, along the lines of "Copy this TXT record into your DNS" or "serve this .txt file from your webserver." This is similar to how DKIM is done today.
- Unlike the DKIM scenario, in the WebPKI case customers will have to copy the policy into both a TXT record and onto their web servers. This is a bit tricky, but the failure scenario is to fail open, so the risks are at least controlled.
- Because of the lack of a way to delegate policies to the host (e.g. for customer.com to delegate its HTTPS-serving to host.com), it's unfortunately tricky for hosts to update the policy without first notifying all of their customers (unless the host is also the DNS or HTTPS host for the customer).
What CAs should senders trust? Will CA trust failures be catastrophic because there's no UI to allow users to override such failures?
We do not specify the set of trusted CAs; this is up to the sender. A frequently mentioned concern with this design is the risk that, unlike with browsers, users will be unable to override trust failures because there is no UI with which to do so. I (editorializing a little) believe this fear to be mostly overstated; modern browsers make it fairly difficult to use untrusted CAs, to the point that this is unlikely to be an acceptable user flow, thus removing it seems of little concern. Conversely, major browsers have, in the past, successfully removed some CAs, a process that I believe works. So maintaining this flexibility and not specifying a canonical set of trusted CAs is a feature, not a bug.
You can use any hosting provider who can serve HTTPS for your domain. (For hosting providers, SNI (supported by e.g. Apache) may be a reasonable option.)
No; the policy will not authenticate. (Unauthenticated policies will be ignored, so mail will continue to flow, but without the security that STS provides.) We do not, however, mandate which CAs will or should be trusted; see "Which CAs should senders trust?".
No. And we do not specify a key usage constraint. We expect policy retrieval to be "standard" HTTPS, so anything that validates for the policy URI should be accepted.