[Uta] draft-ietf-uta-mta-sts-04 Review

[<[e-mail]>]

Some minor comments and a question on policy updates.

_ Section 3.2 MTA-STS Policies, when describing the "mx" parameter, it says:

"For example, "["mail.example.com", ".example.net"]" indicates that
mail for this domain might be handled by any MX with a certificate
valid for a host at "example.com" or "example.net"..."
Should't it say: " valid for a host at 'mail.example.com'"?

_ Section 3.3 HTTPS Policy Fetching

"When fetching a new policy or updating a policy, the HTTPS endpoint
MUST present a X.509 certificate which is valid for the "mta-sts"
host (as described in [RFC6125]), chain to a root CA that is trusted
by the sending MTA, and be non-expired."
 Maybe it's redundant, but since it explicitly mention non-expired,
should it also mention not revocated?

"If a valid TXT record is found but no policy can be fetched via
HTTPS, and there is no valid (non-expired) previously-cached policy,
senders MUST treat the recipient domain as one that has not
implemented MTA-STS."
 I think that a better option would be to report the recipient and
continue with opportunistic TLS.

_ Section 4 Policy Validation:

"2.  That at least one of the policy's "mx" patterns matches at least
     one of the identities presented in the MX's X.509 certificate, as
     descriped in "MX Certificate Validation"."

The last line should say "described in ..."


_ Section 4.1 MX Certificate Validation: (Same than in section 3.3 about certificates)

"The certificate presented by the receiving MX MUST chain to a root CA
that is trusted by the sending MTA and be non-expired. "
 Maybe it's redundant, but since it explicitly mention non-expired,
should it also mention not revocated?

_ Section 5.1 Policy Application Control Flow

"3. Upon message retries, a message MAY be permanently failed
    following first checking for the presence of a new policy (as
    indicated by the "id" field in the "_mta-sts" TXT record)."

It does not specify the number of retries. A parameter could be added to
the policy to indicate the number of retries before permanent failure,
with a default value of X.

Maybe I missed it, but I didn't see any mention to what to do if
the id from the TXT record does not match the id from the HTTPS policy.

_ Security considerations:

The first paragraph of Section 6.1 contradicts the second paragraph on Section 8.3

  "Updating the policy requires that the owner make changes in two
   places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and
   at the corresponding HTTPS endpoint.  As a result, recipients should
   thus expect a policy will continue to be used by senders until both
   the HTTPS and TXT endpoints are updated and the TXT record's TTL has
   passed." (1st paragraph Section 6.1)

  "This attack is mitigated in part by the ability of a victim domain to
   (at any time) publish a new policy updating the cached, malicious
   policy, though this does require the victim domain to both obtain a
   valid CA-signed certificate and to understand and properly configure
   MTA-STS." (2nd paragraph Section 8.3)

   If I am able to publish a new policy, but this policy does not reach
   the senders, then I am not solving the problem.

The whole policy application, update is not clear to me, it seems there is
a contradiction between the fact, mentioned a couple of times, that a policy
can be updated any time, and the resistance to "TLS downgrade" attacks. Please
correct me if I'm wrong.

In the policy updates, it clearly states that updating a policy requires
updating both the TXT record and the HTTPS policy.

DNS request are usually served by intermediary DNS servers, that will update
the cache based on the TTL of records, whereas HTTPS requests will be usually
served by the "final" server itself, therefore policy updates will immediately
(almost) be deployed.

This creates a dilemma. Using short TTLs to allow frequent policy updates increases
the window of vulnerability (policy update requires fetching the TXT record),
but using long TTLs reduces the ability to update the policy on-demand.

A possible solution could be to unlink the id from the TXT record from the id of the policy.
A long TTL (1 month?) can be used to "broadcast" that a domain applies MTA-STS, and a short
max-age (hours, minutes?) can be used to facilitate frequent policy updates.

Finally, regarding the JSON vs pair-of-values,  I think that at this stage the opinion of the
Implementors (those who will implement it) should prevail, to facilitate its future acceptance.
I don't think it makes much difference for domain controllers, who may deploy it.

Gerard Draper Gil