-
Notifications
You must be signed in to change notification settings - Fork 19
Why not support DNSSEC
The best place to get some context on this discussion is Viktor's thoughtful comments here: https://mailarchive.ietf.org/arch/msg/uta/Sna_Va0qNNTCpfEe6KeUfbdoKv4. In particular, I am trying to summarize his suggestions around how to use DNSSEC (if at all) in STS.
As drafted in v0, STS allowed a policy to authenticate using one of two options:
a=dnssec OR a=webpki
The former is simply standard DNSSEC validation of the TXT record that holds the policy. The latter works using the mechanism, described in the draft, of first fetching the policy from a TXT record and then comparing it (byte-for-byte) with the same policy fetched and authenticated via HTTPS from example.com/.well-known/smtp-sts.
The policy can also specify
c=tlsa OR c=webpki
The latter requires that the MTA's certificates validate using the WebPKI method (described in more detail in the draft). The former implies that the MX should validate using DANE TLSA, but the significance of this is a bit ill-defined: TLSA already applies (or not) if a record exists. So c=tlsa is really just a way of making explicit that the STS policy around reporting should apply to DANE failures, as well.
Following discussion, we made the following changes:
This constraint mostly produces confusion, since a policy with "report-only mode" suggests that DANE TLSA should not be enforced (which is contrary to the DANE protocol!). So we can assume we only ever want to send reports for DANE failures; we don't want to change DANE behavior. Thus if we simply specify that STS reports may or should contain statistics around additional authentication failures--including any from future protocols not yet designed--we are both future-proof and able to remove c=tlsa.
This is mostly a no-op; we should change reporting thus anyway, so it really just clarifies the draft.
This change is not a no-op.
Removing a=dnssec would simplify the protocol in that it simplifies the requirements on validating a policy: there's no longer the risk that a sender may be unable to validate some policies because that sender does not have a validating resolver. (For doing anything more than reporting of DANE failures, senders already need WebPKI, so that's the minimum common denominator.)
As a result, "implements STS" has a singular meaning for senders (modulo "reporting" vs" enforcing"), whereas adding the possibility for DNSSEC policy validation adds another dimension of potential incompatibility between senders and recipients.
In addition, removing a=dnssec enables us to simplify the protocol, as described below.
If policies were always validated by HTTPS (as described above), then we wouldn't need a policy in the TXT record at all--just a version indicator, to (ab)use DNS's caching and allow senders to cheaply detect when to look for a refreshed policy. This could be done by sticking any old string in the TXT record--a nonce, hash of the version, date string, monotonically-increased number, or whatever. (The sender need not care how this is generated; the sender should merely cache the policy and version string, so as to detect when the version string has changed.)
This presents two advantages:
-
It simplifies deployment a little bit; policy domains can update the published policy via HTTPS and then flip the version string separately; at no point will senders see an invalid (i.e. mismatched between TXT and HTTPS) policy.
-
It simplifies hosted usage quite a bit. A mail hosting provider can also host an HTTPS endpoint that serves the most up-to-date policy (using SNI to sign with the customer's certificate), without needing to also put the policy in the customer's DNS zone. This means the host can update the policy at will without the customer needing to do more than increment the version.