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

From: <[email-masked]>
Date: Thu, 6 Apr 2017 09:08:49 +0000

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

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 18 Apr 2017 18:15:09 +0200

> Should't it say: " valid for a host at 'mail.example.com'"?
Yes! Thanks. Fixed in Github and the next draft.

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

> continue with opportunistic TLS.

Agreed. Added.

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

Fixed.

> should it also mention not revocated?

See above.

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

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

> can be updated any time, and the resistance to "TLS downgrade" attacks.

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?

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

> I don't think it makes much difference for domain controllers, who may

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Apr 2017 17:23:01 +0100

Hi Daniel,

On 18/04/2017 17:15, Daniel Margolis wrote:
> On Thu, Apr 6, 2017 at 11:08 AM, <[email-masked] 
> <mailto:[email-masked]>> wrote:

> 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.
>
> knowledge, the state of deployment is haphazard, so it seems a bit 
> risky to require it.)

RFC 5280 mention it. I think you need to make it clear that checking 
OCSP is not prohibited here. (Maybe say "MAY use OCSP to check for 
revocation" or similar.)

Best Regards,
Alexey

---

From: Daniel Margolis <[email-masked]>
Date: Sat, 22 Apr 2017 19:11:11 +0200

Thanks for the pointer.

Yes, I of course have no objections to checking CRL or OCSP. Given the
mixed state of deployments among browsers, it merely seems worrisome to me
to *require* that. MAY seems like a good clarification to have here.

On Tue, Apr 18, 2017 at 6:23 PM, Alexey Melnikov <[email-masked]>
wrote:

> RFC 5280 mention it. I think you need to make it clear that checking OCSP
> is not prohibited here. (Maybe say "MAY use OCSP to check for revocation"
> or similar.)
>
> Best Regards,
> Alexey
>
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 22 Apr 2017 21:31:58 -0400

> On Apr 22, 2017, at 1:11 PM, Daniel Margolis <[email-masked]> wrote:
> 
> Thanks for the pointer. 
> 
> Yes, I of course have no objections to checking CRL or OCSP. Given the mixed
> state of deployments among browsers, it merely seems worrisome to me to require
> that. MAY seems like a good clarification to have here.

MAY is fine.  Postfix has no support for CRLs or OCSP.  CRLs will never be supported,
I might support OCSP stapling some day, but not very soon.

Exim appears to have OCSP support, but last time I looked at the code, it seemed to
be going through the motions, but not actually validating the OCSP response correctly.

So indeed MUST is rather far from current or likely near-term practice.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 23 Apr 2017 12:10:01 +0100

> be going through the motions, but not actually validating the OCSP response correctly.

Perhaps you could raise specific bugs?
-- 
Cheers,
  Jeremy