Subject: [Uta] Ben Campbell's Yes on draft-ietf-uta-mta-sts-17: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 09 May 2018 19:33:59 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-uta-mta-sts-17: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting "Yes" because I want to see this work published. But I have a few
concerns:

§3 seems to leave much of the interpretation of the TXT record as
"implication". It should be explicit. I'd like to see the specific steps the
sender is supposed to follow (perhaps the flow in §5.1 could be expanded to
include the TXT query and interpretation?

For example, the idea that a non-existent record means no MTA-STS support is
sort of buried in the description of multiple text records. Would it be
reasonable to say that the sender SHOULD NOT query for policy if the id hasn't
changed since a previous query?

§3.3:
- "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" I find this
confusing. Which endpoint is doing the fetching? Which one MUST present the
cert. Are we talking about this in the context of TLS or something else? - Why
is checking for certificate revocation only a MAY? - Does the term "sender"
refer to the SMTP sender, or something else?

§4.1: Why is checking for certificate revocation only a MAY?

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 10 May 2018 15:53:05 +0200

> https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

The specific reason we kept section 5 only about "application" (and not
"fetch"). There is (I hope) a natural abstraction layer between the two.
Perhaps instead we should add a similar "control flow" subsection in
section 3 or 4, if we can figure out what should be in that subsection.

> changed since a previous query?

Just to be clear (though I think this is what you meant), a non-existent
TXT record only means there's no new policy to fetch. It does not say that
STS is not supported, exactly--if the sender has a previously cached and
non-expired policy, the sender MUST apply that cached policy. In other
words, policy fetch failure has no meaning with respect to whether the
recipient domain has implemented STS, and what to do in this case depends
on the state of the sending MTA (whether it has a previously fetched policy
or not).

So a statement like that might bring the clarity you want? What do you
think?

With respect to your last sentence, I'm afraid I don't follow this part. A
sending MTA can certainly query for a new policy even if the TXT record's
ID hasn't changed. I see no reason to--because a working system MUST NOT
require senders to do this--and senders probably SHOULD NOT do this in
order both to a) ensure people use the DNS signalling mechanism
appropriately and b) to save traffic to the HTTPS endpoint--but it's an
operational issue and not one of correctness per se.

§3.3:
> cert. Are we talking about this in the context of TLS or something else?

Yes, this is in reference to the "policy host" (i.e. mta-sts.example.com").
The HTTPS client in this context is the sending MTA. I will try to add some
clarity to that effect.

> - Why
> is checking for certificate revocation only a MAY?

This is discussed a few other places on the working group, but in short, it
seems to me the ecosystem is not exactly on the same page with respect to
revocation. From my rather limited knowledge, OCSP Must-Staple is probably
the only currently-viable option (in terms of having the security and
functional properties we want), but is not widely supported in MTA land
(e.g. Postfix does not support OCSP at all). If there's a meaningful (i.e.
in our threat model) and widely implemented/applicable approach here, we
should use it, but I don't think there is.

(For HTTPS, revocation is maybe more viable, but absent revocation support
on the SMTP TLS channel it doesn't really help to require it in one place.)

> - Does the term "sender"

Yes, the SMTP sender. I can clarify this--can you help me by pointing out
the places this stands out as confusing language? Or should it just be
included in the Terminology section?

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 10:43:24 -0400

> On May 9, 2018, at 10:33 PM, Ben Campbell <[email-masked]> wrote:
> 
> Would it be

Actually, it would not.  The reason is that MTAs actually should refresh the
policy proactively before it expires, provided there's ongoing traffic to
the policy domain (recipient domain or smarthost).   The details of the
timing are implementation dependent, but the idea is to keep the policy
"warm" rather than let it expire and start cold.

If the id has not changed, the policy does not need an ASAP refresh, and
can be refreshed on the more leisurely proactive schedule.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 10 May 2018 16:55:07 +0200

I slightly disagree with your reasoning, though I agree with the
conclusion.

Sender should, as we have talked about in the past, feel free to
proactively check for new policies, but there's no real reason for them to
check via HTTPS. If they check the TXT record and the ID has not changed,
they shouldn't feel any need to go to HTTPS anyway--the only reason to do
this is if the recipient has screwed up their DNS, and we should not
necessarily want to encourage that by allowing the system to be robust to
such errors, right?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 11:21:17 -0400

> On May 10, 2018, at 10:55 AM, Daniel Margolis <[email-masked]> wrote:
> 
> I slightly disagree with your reasoning, though I agree with the conclusion. 
> 
> Sender should, as we have talked about in the past, feel free to proactively check for new policies, but there's no real reason for them to check via HTTPS. If they check the TXT record and the ID has not changed, they shouldn't feel any need to go to HTTPS anyway--the only reason to do this is if the recipient has screwed up their DNS, and we should not necessarily want to encourage that by allowing the system to be robust to such errors, right? 

Actually, not right.

1. The TXT record should be checked on every connection, and trigger an
   ASAP policy update if changed.

2. The purpose of proactive refresh that is NOT based on a changing TXT
   record is to update the *policy expiration time*, moving further into
   the future, thus avoiding a cold start on policy expiration.

Indeed there is a problem I've failed to notice in Section 10.2:

   Because this attack is also possible upon refresh of a cached policy,
   we suggest implementers do not wait until a cached policy has expired
   before checking for an update; if senders attempt to refresh the
   cache regularly (for instance, by checking their cached version
   string against the TXT record on each successful send, or in a
   background task that runs daily or weekly), an attacker would have to
   foil policy discovery consistently over the lifetime of a cached
   policy to prevent a successful refresh.

It seems to suggest that just periodic checks of the TXT records are
enough, but they're not.  Many sites will have a fixed unchanging policy
for a long time, and therefore a fixed non-changing TXT record id.  So,
absent a proactive periodic HTTPS poll, the policy will expire and the
cold start attack will come into play.

A correct MTA-STS implementation should check the TXT record on every
connection (DNS lookups are cheap, locally cached, MTAs don't mind the
small latency blip, ...).  A robust MTA-STS implementation that avoids
downgrade to cold-start SHOULD also proactively refresh the policy via
HTTPS.  If/when this is done in Postfix, it will likely be after half
remaining expiration time since last fetch attempt (shortly after the
first delivery to the destination after such a time).

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 10 May 2018 18:16:39 +0200

Yes, you're right. I take back my comment, though I'm glad I made it since
it clarified this whole thing. ;)

I've rewritten this to

Because this attack is also possible upon refresh of a cached policy, we suggest
implementers do not wait until a cached policy has expired before checking for
an update; if senders attempt to refresh the cache regularly (for example, by
checking their cached version string against the live policy in a background
task that runs daily or weekly and updating their cache's "max age"
accordingly), an attacker would have to foil policy discovery consistently over
the lifetime of a cached policy to prevent a successful refresh.

and will push it in the next draft (barring objections).

Thanks!

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 12:44:38 -0400

> On May 10, 2018, at 12:16 PM, Daniel Margolis <[email-masked]> wrote:
> 
> Yes, you're right. I take back my comment, though I'm glad I made it since it clarified this whole thing. ;) 
> 
> I've rewritten this to 
> 
> accordingly), an attacker would have to foil policy discovery consistent

I don't understand what is meant by "checking their cached version string"
in:

  (for example, by checking their cached version string against the
  live policy in a background task that runs daily or weekly and
  updating their cache's "max age" accordingly)

Can you elaborate.  Are you saying that it is enough to check that
the TXT record has not changed to extend the policy max_age?  Without
connecting to the HTTPS site?

Does that mean that a site that removes its "mta-sts" HTTPS service
endpoint but keeps a stable TXT record in place will be able to
indefinitely support policies at senders who originally obtained
the policy?

I am ambivalent about this approach.  For example, if a site does
the DNS and HTTPS updates out of order, a sender might never learn
the right (most recent) policy...

Or am I misreading the new text?

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 10 May 2018 20:13:16 +0200

No, it's just a rushed edit on my part. My intent was t say that you should
check the cached version against the version in HTTPS.

One *could* argue (as you speculated) that as long as the TXT is there, one
can bump the max-age parameter in the cache and not bother to do the HTTPS
fetch (since it should be a foregone conclusion). I don't see a problem
with that, really.

(In the problematic example you give, a sender can still only cache the old
version for as long as the TXT is unchanged, which is allowed in the
specification!)

In short, I think your interpretation (which was not my intent) works
perfectly fine, though I don't know that we would desire people do that. We
may want to simply not specify this--what we *do* want is for senders to
periodically and in advance of expiration refresh their cached policies;
technically this does not really require HTTPS I don't think, but it
doesn't hurt to do the fetch.

WDYT?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 14:55:30 -0400

> On May 10, 2018, at 2:13 PM, Daniel Margolis <[email-masked]> wrote:
> 
> No, it's just a rushed edit on my part. My intent was t say that you should check the cached version against the version in HTTPS.
> 
> One could argue (as you speculated) that as long as the TXT is there, one can bump the max-age parameter in the cache and not bother to do the HTTPS fetch (since it should be a foregone conclusion). I don't see a problem with that, really. 
> 
> (In the problematic example you give, a sender can still only cache the old version for as long as the TXT is unchanged, which is allowed in the specification!) 
> 
> In short, I think your interpretation (which was not my intent) works perfectly fine, though I don't know that we would desire people do that. We may want to simply not specify this--what we do want is for senders to periodically and in advance of expiration refresh their cached policies; technically this does not really require HTTPS I don't think, but it doesn't hurt to do the fetch. 
> 
> WDYT?

I think that extending the max_age based on just seeing the same TXT id,
while quite tempting from a performance perspective, is potentially risky.

I'm inclined to be more conservative and require at least one actual
HTTPS policy lookup per max_age interval.  This would mean that a policy
expiration would never be extended without an HTTPS confirmation.  The
TXT record is then at most a policy "staleness" signal (including having
a "stale" no-policy).

Hybrid approaches are possible, but I don't think they are warranted.
Perhaps some others should chime in as well...

-- 
	Viktor.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 May 2018 16:48:58 -0500

On May 10, 2018, at 8:53 AM, Daniel Margolis <[email-masked] <mailto:[email-masked]>> wrote:

> 
> 
> On Thu, May 10, 2018 at 4:34 AM Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ <https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/>
> 
> 
> 
> The specific reason we kept section 5 only about "application" (and not "fetch"). There is (I hope) a natural abstraction layer between the two. Perhaps instead we should add a similar "control flow" subsection in section 3 or 4, if we can figure out what should be in that subsection. Questions below:
> 
> Just to be clear (though I think this is what you meant), a non-existent TXT record only means there's no new policy to fetch. It does not say that STS is not supported, exactly--if the sender has a previously cached and non-expired policy, the sender MUST apply that cached policy. In other words, policy fetch failure has no meaning with respect to whether the recipient domain has implemented STS, and what to do in this case depends on the state of the sending MTA (whether it has a previously fetched policy or not).

That seems to be contradicted by the following sentence in the last paragraph of §3.2...

"If the number of resulting records is not one, senders MUST assume the recipient domain does not implement MTA-STS and skip the remaining steps of policy discovery.”

… since zero records in not one.

> 
> So a statement like that might bring the clarity you want? What do you think?

Possibly. For the record, I don’t have strong feelings what the procedures should be, just that they should be clear and explicit :-)

> 
> With respect to your last sentence, I'm afraid I don't follow this part. A sending MTA can certainly query for a new policy even if the TXT record's ID hasn't changed. I see no reason to--because a working system MUST NOT require senders to do this--and senders probably SHOULD NOT do this in order both to a) ensure people use the DNS signalling mechanism appropriately and b) to save traffic to the HTTPS endpoint--but it's an operational issue and not one of correctness per se.

I see discussion has ensued on this point, so I will await the outcome of that.

> Yes, this is in reference to the "policy host" (i.e. mta-sts.example.com <http://mta-sts.example.com/>"). The HTTPS client in this context is the sending MTA. I will try to add some clarity to that effect.

That would help. It would also help to add text clarifying that “presenting a certificate” happens in the context of a TLS handshake for the HTTPS transaction.  (assuming that is the intent.)

> This is discussed a few other places on the working group, but in short, it seems to me the ecosystem is not exactly on the same page with respect to revocation. From my rather limited knowledge, OCSP Must-Staple is probably the only currently-viable option (in terms of having the security and functional properties we want), but is not widely supported in MTA land (e.g. Postfix does not support OCSP at all). If there's a meaningful (i.e. in our threat model) and widely implemented/applicable approach here, we should use it, but I don't think there is.
> 
> (For HTTPS, revocation is maybe more viable, but absent revocation support on the SMTP TLS channel it doesn't really help to require it in one place.)

A possible approach here would be to forgo the MAY, and just say why might want to check for revocation and the possible consequences of not doing so.

> Yes, the SMTP sender. I can clarify this--can you help me by pointing out the places this stands out as confusing language? Or should it just be included in the Terminology section?

Basically anywhere “sender” is used without qualification. Including it in the Terminology section would probably be fine.

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 11 May 2018 10:41:22 +0100

Hi all,

> On 10 May 2018, at 22:48, Ben Campbell <[email-masked]> wrote:
> 
>>> - Does the term "sender"

Yes, “sender” is a common SMTP term, so adding it to the Terminology section makes sense.

Best Regards,
Alexey

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 11 May 2018 13:29:38 +0200

On Thu, May 10, 2018 at 11:49 PM Ben Campbell <[email-masked]> wrote:

>
>
> On May 10, 2018, at 8:53 AM, Daniel Margolis <[email-masked]> wrote:
>
>
>
> "If the number of resulting records is not one, senders MUST assume the
> recipient domain does not implement MTA-STS and skip the remaining steps
> of policy discovery.”
>

Right, good point. The intended meaning of that phrase is that it signals
the recipient domain does not currently have an STS policy (and should skip
the rest of policy discovery); what that results in depends on whether
there is a previously cached policy. I will try to clarify this a bit more:

If the number of resulting records is not one, senders MUST assume the
recipient domain
does not have an available MTA-STS policy and skip the remaining steps of policy
discovery.  (Note that lack of an available policy does not signal opting out of
MTA-STS altogether if the sender has a previously cached policy for the
recipient domain, as discussed in (#policy-application-control-flow), "Policy
Application Control Flow".)

> Possibly. For the record, I don’t have strong feelings what the procedures
> should be, just that they should be clear and explicit :-)
>
>
> That would help. It would also help to add text clarifying that
> “presenting a certificate” happens in the context of a TLS handshake for
> the HTTPS transaction.  (assuming that is the intent.)
>

Done:

During the TLS handshake initiated to fetch a new or updated
policy from the Policy Host, the Policy Host HTTPS server MUST present a X.509
certificate which is valid for the `mta-sts` DNS-ID ([@?RFC6125]) (e.g.,
`mta-sts.example.com`) as described below, chain to a root CA that is trusted by
the sending MTA, and be non-expired.

> This is discussed a few other places on the working group, but in short,
> it seems to me the ecosystem is not exactly on the same page with respect
> to revocation. From my rather limited knowledge, OCSP Must-Staple is
> probably the only currently-viable option (in terms of having the security
> and functional properties we want), but is not widely supported in MTA land
> A possible approach here would be to forgo the MAY, and just say why might
> want to check for revocation and the possible consequences of not doing so.
>

Note also the following text in the Security Considerations section:

Broadly speaking, attackers may compromise the system by obtaining certificates
under fraudulent circumstances (i.e., by impersonating the legitimate owner of
the victim domain), by compromising a Certificate Authority or Delegate
Authority's private keys, by obtaining a legitimate certificate issued to the
victim domain, and similar.

One approach commonly employed by Web browsers to help mitigate against some of
these attacks is to allow for revocation of compromised or fraudulent
certificates via OCSP [@?RFC6960] or CRLs [@?RFC6818].  Such mechanisms
themselves represent tradeoffs and are not universally implemented; we
nonetheless recommend implementors of MTA-STS to implement revocation mechanisms
which are most applicable to their implementations.

Given that, should we still remove the MAY? That seemed appropriate
language ("MAY"), but I'm happy to remove it depending on your feedback--I
just wanted to call out that reasoning is somewhat covered here already.

> Basically anywhere “sender” is used without qualification. Including it in
> the Terminology section would probably be fine.
>

Done.

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 11 May 2018 13:30:55 +0200

Yeah, I think it can go either way. But this is a suggestion we make on
implementations, so I wouldn't worry *too much*; the door is open for
implementors to vary approaches, and either approach (TXT optimization or
not) is still compliant. I have changed the text to this:

Because this attack is also possible upon refresh of a cached policy, we suggest
implementers do not wait until a cached policy has expired before checking for
an update; if senders attempt to refresh the cache regularly (for example, by
fetching currently live policy in a background task that runs daily or weekly,
regardless of the state of the `_mta_sts` TXT record, and updating their cache's
"max age" accordingly), an attacker would have to foil policy discovery
consistently over the lifetime of a cached policy to prevent a successful
refresh.

On Thu, May 10, 2018 at 8:56 PM Viktor Dukhovni <[email-masked]>
wrote:

> > No, it's just a rushed edit on my part. My intent was t say that you
> should check the cached version against the version in HTTPS.
> >
> > One could argue (as you speculated) that as long as the TXT is there,
> one can bump the max-age parameter in the cache and not bother to do the
> HTTPS fetch (since it should be a foregone conclusion). I don't see a
> problem with that, really.
> >
> > (In the problematic example you give, a sender can still only cache the
> old version for as long as the TXT is unchanged, which is allowed in the
> specification!)
> >
> may want to simply not specify this--what we do want is for senders to

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 09:56:10 -0400

> On May 11, 2018, at 7:29 AM, Daniel Margolis <[email-masked]> wrote:
> 
> If the number of resulting records is not one, senders MUST assume the recipient domain

I think it is simpler to say that the text pertains only to policy discovery
when no previous policy is cached.

If a "none" policy cached, and the text record also goes away, I'd delete
the cached policy at that time. 

As an implementor, if some other cached policy is in place, and it has
an associated non-empty id, I'd attempt to refresh the policy and store
any result under the empty id.  That is, treat a missing or malformed TXT
RR as a TXT RR with an empty id when a policy other than "none" is cached.
Once a conformant TXT RR is back in place, the policy will be refreshed
again.  I don't know whether that should be specified, but it seems a
prudent implementation strategy.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 10:04:27 -0400

> On May 11, 2018, at 7:30 AM, Daniel Margolis <[email-masked]> wrote:
> 

Perhaps sufficient.  I would in practice only refresh policies as a side-effect
of ongoing traffic, so that the policy database doe snot become an ever-expanding
museum of every domain ever contacted, to many of which no further mail will be
sent.  That's an implementation choice I guess that depends on the sender's
resources to cache an unbounded number of policies and likelihood to stop sending
to some extant domains.  MTA implementors will therefore need to figure out the
details for themselves...

Or this could mention that the refresh can be contingent on ongoing email
traffic to the domain so as to allow idle cached policies to expire.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 11 May 2018 17:11:53 +0200

Suggested text? :)

I don't know why you'd treat a missing TXT as a signal to look for a new
policy, but it doesn't really hurt, so I guess that's up to you as an
implementor. :)

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 May 2018 11:17:35 -0400

> On May 11, 2018, at 11:11 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Suggested text? :)

With all this kibitzing no time to do anything productive. :-) :-(

> I don't know why you'd treat a missing TXT as a signal to look for a new policy, but it doesn't really hurt, so I guess that's up to you as an implementor. :)

For me, any change of state should trigger a policy check.  If the TXT record
goes away, perhaps the operator of the destination site is doing things in
the wrong order, clue is sometimes scarce.  So I'd re-check the policy.

-- 
	Viktor.