Subject: [Uta] Comments on mta-sts-11

From: Jim Fenton <[email-masked]>
Date: Sun, 12 Nov 2017 03:01:37 -0800

Hi,

On the flight to Singapore, I went through the latest mta-sts draft, and
have a number of comments. Some of these I have probably made before,
but (at the risk of belaboring old items) I think they warrant revisiting.

My overarching concern is whether MTA-STS would be effective against an
attacker that is able to mount a downgrade or man-in-the-middle attack
on STARTTLS. An attacker that is positioned between mail servers to be
able to block the negotiation of STARTTLS probably is also positioned to
be able to block the _mta-sts TXT record response, making it look like
there's no policy.

- In the introduction, it lists as one of the goals countering attacks
by those who can overwrite the resolved MX record of the delivery
domain. This is a good goal, and largely addressed by verifying
certificates, but if DNS attacks are on the table, we need to talk more
about attackers who can block the mta-sts TXT record (see below).

- 2. Related technologies: I wouldn't describe as "upgrading plaintext
transmission" -- if STARTTLS couldn't be negotiated, it still won't.
Suggest upgrade -> inhibit

- Section 2 paragraph 2 makes it sound like DANE does reporting, and it
doesn't. This should refer instead to relevant stuff in tlsrpt.

- Section 3.2 "mode" key/value pair: What does "report" do now that
tlsrpt is separate? It seems like the modes now ought to be "enforce"
and "none".

- max_age: Does expiration of max_age trigger a refresh or does it
simply age out of the cache? I had thought that TXT record suppresion
attacks were mitigated by only requiring the TXT record initially, but
this makes it sound like it ages out and has to be rediscovered the next
time a message is sent to the domain. The paragraph also encourages use
of very long max_age values to mitigate attacks at policy refresh time;
what sorts of attacks are anticipated? Just to be clear, I do not
consider use of long cache times to be an effective security measure.

- Section 3.3: Does certificate expiration constrain the max_age of a
cached policy? (if the certificate expires very soon)

- Section 3.4: #Policy Validation section header looks like an
unconverted section header from Markdown.

- Section #Policy Validation: "does not dictate the behavior of sending
MTAs when policies fail to validate" but following the semicolon it says
that "report" or "none" MUST NOT be interpreted as delivery failures,
which seems like exactly that. Suggest removing "in particular" and
everything before it in the sentence.

- Section 3.5 paragraph 3: Mangled reference to RFC 6125.

- Section 4 "enforce" prohibits delivering when things fail mta-sts, but
Section 2 says, "MTA-STS is designed not to interfere with DANE
deployments where the two overlap". Doesn't this requirement constitute
that sort of interference?

- Section 4 "report": delete? (because this is in tlsrpt)

- Section 6.1: Why is SNI always required? Can't a small MTA that only
ever serves one domain get by without it?

- Section 7.1 leads me to question the benefit of having a policy ID in
the TXT record as opposed to just a hint whether might be a MTA-STS
policy. Apparently the only time the a sender i. required to check the
TXT record is when they don't have a policy (first message or it has
expired). Of course senders could check TXT more often but I don't see
any guidance for that. With the record being checked on max_age
expiration (assuming it doesn't just age out, see question above) and
max_age being expressed in weeks, the number of HTTPS transactions saved
is going to be small. Balance that against the added operational
complexity of having to update both DNS and the policy server when the
policy changes.

- Section 7.2 paragraph 3: Suggest "a host" -> "an address"

- Section 7.3 item 2: This could also be simpler if there is no policy
ID; in any case it's not clear what triggers retrieval of the TXT record
if the sender already thinks it knows a policy for recipient domain.

- Section 9.2 paragraph 1 refers to a "victim sending domain" and 9.3
paragraph 2 refers to a "victim domain" that is apparently the domain
setting up an MTA-STS policy. This terminology needs to be more
consistent. Perhaps avoid use the word "victim" at all (although it
would be good to better understand who benefits from publishing MTA-STS).

- Sections 11 and 12 should be real appendices; xml2rfc can do this.
Should also be marked informative in case there is an inconsistency with
the spec.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 12 Nov 2017 13:48:28 -0500

> On Nov 12, 2017, at 6:01 AM, Jim Fenton <[email-masked]> wrote:
> 
> An attacker that is positioned between mail servers to be

This is an unavoidable feature of STS.  It is vulnerable to "cold start"
downgrade attacks, that is to downgrades when the sending system has
no cached policy.

> tlsrpt is separate? It seems like the modes now ought to be "enforce"

It does exactly what it says, delivery proceeds despite lack of STARTTLS
or authentication failure, but such failures to establish a secure channel
for delivery are reported.  There are no such reports to domains with no
policy.  Perhaps the receiving domain is unsure how interoperable its
TLS stack or certificate chain would be if enforced.  Though to be honest
I am not convinced that support for reporting will be universal, I expect
that some systems will treat "report" and "none" as synonymous (by never
sending reports).

> simply age out of the cache?

A sensible implementation of STS will make (multiple if necessary)
refresh attempts long *before* the cached policy expires, provided
there is sufficient ongoing traffic to the destination domain.

Such refresh would happen after a delivery of a message after 1/2
max_age, 3/4 max_age, ... ultimately down to (say) ~5 minutes before
expiration.  So with a 180 day max_age, and steady message flow to
a domain with a poorly available HTTPS service, the refreshes would
happen (rounded):

	* shortly after 90 days, but failing that
        * shortly after 135 days, but failing that
	* shortly after 157 days, but failing that
	* shortly after 168 days, but failing that
        * shortly after 173 days, but failing that
	* shortly after 177 days, but failing that
        * shortly after 178 days, but failing that
        * shortly after 179 days, but failing that
        * shortly after 12 hours to go, but failing that
        * shortly after 6 hours to go, but failing that
        * shortly after 3 hours to go, but failing that
	* shortly after 90 minutes to go, but failing that
	* shortly after 45 minutes to to, but failing that
	* shortly after 22 minutes to go, but failing that
	* shortly after 11 minutes to go, but failing that
        * shortly after 5 minutes to go, but failing that
	... policy expires ...
	* periodic lookup after each message delivery, but
          not more often than once every (say) 5 minutes.

The details of the refresh policy, and frequency of probes
for domains with no cached policy would be implementation
dependent.  I think that based in part on my feedback the
text in Section 9.2 says (somewhat less prescriptively):

  https://tools.ietf.org/html/draft-ietf-uta-mta-sts-11#section-9.2

  9.2.  Preventing Policy Discovery
   ...

   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.

> I had thought that TXT record suppresion
> time a message is sent to the domain.

See above, refresh should happen long before expiration.  An ongoing
MiTM attack can defeat this, but the attack has to be ongoing for the
lifetime of the policy.  It may be easier to get a forged certificate
from some DV CA (via MiTM of the traffic between the CA and the target
domain).

> Just to be clear, I do not consider use of long cache times to be an
> effective security measure.

If that's the case, then STS is not for you.  DANE has stronger
downgrade resistance, please join the existing > 173000 domains
that have DNSSEC and DANE-enabled MX hosts.  I'd especially like
to see some US-based hosting providers emulate domeneshop.no,
transip.nl, udmedia.de and bhosted.nl by enabling DANE on the
SMTP servers used for their hosted domains.  If anyone reading
this knows the right people at Godaddy, Dreamhost, ... please
let them know I'm available to answer any questions they may
have and suggest key rotation strategies.

> cached policy? (if the certificate expires very soon)

No.  Neither the mta-sts HTTPS server certificate, nor even more so
the expirations of MX host certificates affect the policy expiration
time.

> that sort of interference?

I would read that as "STS is entirely out of scope when DANE policy
is in effect".  Of course sending machines get to decide whether
DANE policy is in effect or not, by choosing to enable DANE or STS
in the first place, and potentially choose one or the other explicitly
for some domains.

Thus, for example, while DANE policy is generally driven by the
remote domain's publishing of TLSA records, a sending Postfix
MTA can be configured to *require* DANE for some set of destinations,
in which case delivery will only happen when the destinations publish
("secure" DNSSEC) DANE TLSA records, and not otherwise.

Similarly, a sending system might *require* STS for some set of
destinations, and refuse to send in the absence of a cached policy.

So, the way I would read and implement this would be to prefer
DANE over STS barring local policy that prefers one over the
other for some destinations or perhaps suppressed both.

> - Section 4 "report": delete? (because this is in tlsrpt)

Sorry, the "report" mode is not superseded by "tlsrpt", which
does not provide any downgrade protected signalling.

> ever serves one domain get by without it?

SNI is required from the *sending* MTA and HTTPS policy lookup client.
It is not (should not be) required at receiving systems, except when they
in fact have multiple certificate chains and need to use the SNI signal
from the client to choose the right one.  Even then, at the MX host
it is required that when the client's SNI does not match any name
known to the server, it should continue and send its default chain.
The HTTPS server can do whatever it is that HTTPS servers do with
SNI, it is not for this specification to redefine HTTPS.

> policy.

This was subject to considerable earlier discussion, and is in fact
needed.

> Apparently the only time the a sender i. required to check the
> expired).

There's your confusion.  This is not the case.

> Of course senders could check TXT more often but I don't see
> any guidance for that.

Section 9.2.

-- 
	Viktor.

---

From: Nicolas Lidzborski <[email-masked]>
Date: Mon, 13 Nov 2017 13:27:21 +0800

> that some systems will treat "report" and "none" as synonymous (by never

Would it make sense to call it "dry-run" or "testing" instead to prevent
confusion and as reporting is now managed in separate TLSRPT?

> does not provide any downgrade protected signalling.

I think renaming "report" as suggested above will remove possible confusion.

> This was subject to considerable earlier discussion, and is in fact

It here to enable checking the currency of a cached policy without fetching
the policy again.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 12 Nov 2017 21:56:04 -0800

> downgrade attacks, that is to downgrades when the sending system has
 Yes -- I'm probably repeating repeating myself here, but thought it
worth saying.

> that some systems will treat "report" and "none" as synonymous (by never

So maybe the problem is the choice of the name "report" since it doesn't
actually cause any reports to be generated. It's really a passive
policy. I was thinking that expressing a policy along with "none" (along
with a tlsrpt policy record) would accomplish this, but maybe the
semantics of "none" are wrong given its role in removing MTA-STS
(Section 7.3), but I don't see that it necessarily conflicts. Or maybe
just change it to enforce: [yes/no].

> dependent.

Without some guidance (perhaps a SHOULD), many implementations will
never check the TXT record if they have a policy in their cache. Unless
senders are going to be actually checking the TXT records for updates,
it's not worthwhile for recipient domains to publish them. I also wonder
how useful it is given that recipient domains are going to have to
assume that their policies will be used until max-age anyway, and these
policies aren't likely to change very often.

>   I think that based in part on my feedback the

A comment that I forgot to make is that, if this is a normative
requirement (even a MAY or SHOULD), it should be in one of the earlier
sections of the document, not in Security Considerations where it's
likely to be overlooked by implementers.

> the expirations of MX host certificates affect the policy expiration

I'm wondering if the document should say that.

> other for some destinations or perhaps suppressed both.

That's the way I would read and implement it too, but it would be good
to say that in Section 4 so that it doesn't conflict with Section 2.

> SNI, it is not for this specification to redefine HTTPS.

Agreed, so the text shouldn't unconditionally require SNI.

> There's your confusion.  This is not the case.

Please point me at text that says otherwise.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 13 Nov 2017 16:06:11 +0000

Hey, thanks to you both for the discussion. I'll try to centralize the
issues here a little bit, if you don't mind.

> Security properties of policy discovery and risks of persistent MITM
preventing discovery.

I'm going to take a pass on this discussion, Jim, unless it's a blocker. As
Viktor said, this is a tradeoff that's been there since the beginning, but
we've discussed it many times before and resolved (I think) to go forward.
So this is simply a risk we have to document, as we have done in Security
Considerations.

> Mode "report" vs "none".

You make a fair point that "report" is a no-op if there's no TLSRPT, but I
think it's somewhat nice to call it out as "report" because it indicates
the likely usage of this setting--to generate data for observers. This
isn't TLSRPT-specific; it's just that absent TLSRPT or human intervention
there's no good way to share reports with the domain admin.

Nicolas's suggestion of "testing" works for me, but frankly I would prefer
not to change this since it requires changing a bit of code in a few places
and will take a few minutes longer than it takes for me to just say I'd
prefer to be lazy and keep "report". If you feel strongly, let me know. ;)

> SNI

To be clear, SNI is only required to be *sent* by the SMTP and HTTPS
clients. This is necessary in that servers cannot use SNI if they cannot
assume clients will send it. But that doesn't mean servers must support
SNI; they can simply ignore it if they want. So this is the minimum
requirement to make SNI functional, as was discussed on this list before.

> Cert validity and max_age.

There's no relationship at all between max_age and cert lifetimes.
Certificate validation involves checking the cert as one normally would,
i.e., by verifying the signing chain and the expiry (and, optionally,
revocation). There's no implication of policy ages applying to anything
other than the policy, I think. I'm happy to clarify this if you suggest
language, of course.

> How strongly to require senders to proactively refresh the policy (as
currently in 9.2).

I'm OK with moving this up in the doc and making it more prominent. I don't
know if we want to make it normative (MUST) because a) the system works
"fine" without it and b) there's no way to really say someone is "not
compliant" if they don't do this. But I think it makes sense to make it a
SHOULD and (as discussed already in Security Considerations) make clear the
risks in not doing so regularly.

Beyond that, I think most of the comments are (much needed) editorial and
formatting fixes, which I very much appreciate, but I think there were no
blockers I missed. Correct me if I'm wrong.

Of course we will take a stab at all of those fixes shortly.

Thanks again!

On Mon, Nov 13, 2017 at 6:56 AM Jim Fenton <[email-masked]> wrote:

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 13 Nov 2017 18:16:22 -0800

> issues here a little bit, if you don't mind.

Good summary, thanks for organizing it. Comments inline.

> I'm going to take a pass on this discussion, Jim, unless it's a
> blocker. As Viktor said, this is a tradeoff that's been there since
> the beginning, but we've discussed it many times before and resolved
> (I think) to go forward. So this is simply a risk we have to document,
> as we have done in Security Considerations.

OK.

>
> > Mode "report" vs "none".
>
> You make a fair point that "report" is a no-op if there's no TLSRPT,
> but I think it's somewhat nice to call it out as "report" because it
> indicates the likely usage of this setting--to generate data for
> observers. This isn't TLSRPT-specific; it's just that absent TLSRPT or
> human intervention there's no good way to share reports with the
> domain admin. 
>
> Nicolas's suggestion of "testing" works for me, but frankly I would
> prefer not to change this since it requires changing a bit of code in
> a few places and will take a few minutes longer than it takes for me
> to just say I'd prefer to be lazy and keep "report". If you feel
> strongly, let me know. ;)

I'm mixed on this. This is at the draft stage so some changes should be
expected. The key question that I have, and implementers will need to
know, is if there is any semantic difference between "report" and
"none". I can't find any, except possibly in Section 7.3, "Removing
MTA-STS", and I'm not sure if that is really a difference. My main
concern with "report", which I probably said before, is that it might
confuse domains that are publishing MTA-STS policies and don't know
about TLSRPT.

>
> > SNI
>
> To be clear, SNI is only required to be /sent/ by the SMTP and HTTPS
> clients. This is necessary in that servers cannot use SNI if they
> cannot assume clients will send it. But that doesn't mean servers must
> support SNI; they can simply ignore it if they want. So this is the
> minimum requirement to make SNI functional, as was discussed on this
> list before.

My mistake here; the spec does clearly say the client MUST have SNI
support, not the server.

> Certificate validation involves checking the cert as one normally
> would, i.e., by verifying the signing chain and the expiry (and,
> optionally, revocation). There's no implication of policy ages
> applying to anything other than the policy, I think. I'm happy to
> clarify this if you suggest language, of course.

Seems reasonable, it's just a question that came up in my head while I
was reading the spec.  Not sure it warrants clarification.

>
> > How strongly to require senders to proactively refresh the policy
> (as currently in 9.2).
>
> I'm OK with moving this up in the doc and making it more prominent. I
> don't know if we want to make it normative (MUST) because a) the
> system works "fine" without it and b) there's no way to really say
> someone is "not compliant" if they don't do this. But I think it makes
> sense to make it a SHOULD and (as discussed already in Security
> Considerations) make clear the risks in not doing so regularly.

Yes, please move it up. Security considerations is more of a discussion
of the characteristics of the protocol, and implementers are likely to
miss it there. I would also add, since it's a SHOULD: Publishers of
MTA-STS policies MUST NOT depend on updates to be retrieved before the
expiration of the max_age.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Nov 2017 22:45:03 -0500

> On Nov 13, 2017, at 9:16 PM, Jim Fenton <[email-masked]> wrote:
> 
> I'm mixed on this. This is at the draft stage so some changes should be expected. The key question that I have, and implementers will need to know, is if there is any semantic difference between "report" and "none".

There is a semantic difference:

* With "none" no verification of the destination is expected and
  no reports are generated on verification "failure"

* With "report", verification is expected, and failure reports
  may be generated, but delivery proceeds despite failure.

The request to "report" failures is subject to the usual downgrade
protection (except on cold-start, loss of state at the sending MTA,
or too little traffic to keep the cache "warm").

-- 
	Viktor.

---

From: 🔥 Nicolas Lidzborski <[email-masked]>
Date: Tue, 14 Nov 2017 13:58:10 +0800

On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni <[email-masked]>
wrote:

> expected. The key question that I have, and implementers will need to know,
> is if there is any semantic difference between "report" and "none".
>
I would suggest calling this mode "disabled" for clarity.

>   may be generated, but delivery proceeds despite failure.
As mentioned, I would suggest renaming this mode "testing" for clarity.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 14 Nov 2017 08:51:57 +0000

Works for me. To sum up the thread:

1. Bunch of editorial stuff. I will try to collate the list from Jim's
original email sometime next week and get it into a new draft. I expect we
may have some feedback from the UTA session as well. ;)

2. Rename "report" to "testing". Not a big deal, I agree, and a bit more
clear.

3. Jim's suggested language with a SHOULD on proactive policy refresh and a
MUST NOT on publishers expecting that to happen.

I think that's all of it?

Thanks everyone.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Nov 2017 16:04:44 +0100

On 2017-11-14 09:51, Daniel Margolis wrote:
> original email sometime next week and get it into a new draft. I expect
> we may have some feedback from the UTA session as well. ;)
> 
> 3. Jim's suggested language with a SHOULD on proactive policy refresh
> and a MUST NOT on publishers expecting that to happen. 
> 

Yeah I think so. I think we can treat these things as WGLC comments.

Barring people speaking up on new things at the meeting tomorrow I
expect to push the IESG button on MTA-STS and TLSRPT sometime next
week or so.

	Cheers Leif

> Thanks everyone. 
> 
> 
> On Tue, Nov 14, 2017 at 6:58 AM 🔥 Nicolas Lidzborski <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Tue, Nov 14, 2017 at 11:45 AM, Viktor Dukhovni
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         > On Nov 13, 2017, at 9:16 PM, Jim Fenton <[email-masked] <mailto:[email-masked]>> wrote:
>         >
>     [email-masked] <mailto:[email-masked]>