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

[Daniel Margolis <[e-mail]>]

On Thu, Apr 6, 2017 at 11:08 AM, <[e-mail]> wrote:

> 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'"?
>
>
Yes! Thanks. Fixed in Github and the next draft.


> _ 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?
>

Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in
practice it varies by implementation, such that some major browsers do not
implement one or the other--I would not want to mandate it here, even if
it's a good idea.

(And I agree it's a good idea in the abstract, but to my very limited
knowledge, the state of deployment is haphazard, so it seems a bit risky to
require it.)


> "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.
>

Agreed. Added.


>
>
> _ 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 ..."
>

Fixed.


>
>
>
>
> _ 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?
>

See above.


>
>
> _ 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.
>

This is up to the sending MTA. We mandate a minimum retry count only in
order to ensure that cached policies are refreshed before any message is
perm-failed. In any reasonable implementation, you probably have some high
number of retries with backoff, but I think it's appropriate to leave it to
MTA implementors (who already have similar configurations for things like
MX lookup failures or server temp-failures.


>
>
> 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.
>

We have removed the ID from the HTTPS policy, so this cannot happen. :)


>
>
> _ 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.
>

I am not sure I understand you. If you can publish a new policy _and_ it is
reachable, you can update any maliciously-published policy. If you cannot
publish a new policy and have senders fetch it because the MITM is ongoing,
a DoS is possible in any event (someone who can DoS HTTPS fetches can, *at
the time*, also DoS SMTP directly). So the only concern here is that a
temporary MITM against DNS/HTTPS can become a long-term MITM against SMTP
(due to policy caching), which is mitigated by the ability to publish a new
policy *once the MITM is over*. Does that address your question?



> 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.
>

The DNS TTL is independent of the max_age. Using a reasonably short DNS TTL
is probably a good idea--say, something similar to the TTL on the MX
records. Using a long policy max_age is also a good idea, for the reason
you suggest.

So using a short DNS TTL does not introduce any real vulnerability that I
can see, does it?


> 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.
>

I unfortunately don't know everyone's names, so I don't know who is an
implementor and who is not. :)

I've hopefully made clear that I don't personally have a strong opinion
about this, but I hope we can reach a consensus that most people are
reasonably comfortable with.


>
>

>
> Gerard Draper Gil
>
>
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>
>