Subject: [Uta] Comments on draft-ietf-uta-mta-sts-03

From: Federico Santandrea - Diennea <[email-masked]>
Date: Mon, 27 Mar 2017 08:08:21 +0000

Here's something that came to my mind while reading draft-ietf-uta-mta-sts-03.

Let's suppose the sending MTA finds the MTA-STS TXT record, which states
the receiving domain has an MTA-STS policy. The draft says "To discover
if a recipient domain implements MTA-STS, a sender need only resolve a
single TXT record". But what happens when the sending MTA can't fetch
the actual policy via HTTPS?

Now the sending MTA knows MTA-STS should be in place, but can't know
what the list of expected MX is. It has to decide what to do.

- If it refuses to send the message, and the (unreachable) policy states
    that it is in "report" mode, this can be considered a denial of
    service.

- If instead it falls back to deliver the message to any available MX,
    either encrypted or in plain text, or even acts as if the domain had
    not stated it had an MTA-STS policy at all; and the (unreachable)
    policy states that it is in "enforce" mode, then effectively this
    was degraded to opportunistic.

Making the HTTPS endpoint unreachable is just a DDoS attack away. This
would expose all first-contact sending MTAs to this conundrum. I think
there is a need to clearly state what must be done in such a situation.
For example we could add to Section 3.3:

"If a MTA-STS TXT record is found but no policy can be fetched from the
HTTPS endpoint, and there is no previous cached policy, then senders
MUST assume the recipient domain does not implement MTA-STS."

While this does not really improve the situation, it makes clear for the
implementor of the receiving side that this is effectively equivalent to
opportunistic encryption and allows for countermeasures to be considered.

The reason for the "no previous cached policy" part is to provide for
the first-contact scenario, but there is another one: what if instead
the sender has previously seen a policy for the domain, but now it's
expired (because of max_age or new id in the TXT record) and it can't
fetch a new one?

I propose that we let the domain owner decide, by stating it in the
at a time when it was reachable. We could add a "fallback_mode" property
to the policy object, with possible values: "block", "keep_expired",
"opportunistic" (names are provisional and for illustration only).

This property would define what the sending MTA is to do when it must
fetch a new policy but can't:

  - "block" would state confidentiality is still favored over
    availability, therefore since the new expected MX list is not
    known (and might be missing compromised servers), messages must
    be discarded or retried at a later time when the endpoint might
    be available again;

  - "keep_expired" would keep applying the cached policy, which would
    not be discarded until it's possible to fetch a new one. I see this
    as useful because to me it's often the case that an expired policy
    would be more useful than no policy at all.

  - "opportunistic" would say that, in this non-normal scenario,
    availability is to be favored over availability, so the sender
    should discard the expired policy and act like in the previously
    explained first-contact scenario.

The last one of course would mean that it's possible to force a fall
back to plaintext by making the HTTPS endpoint unavailable until a
policy expires, but the domain owner would have chosen this explicitly
and has to understand that.

--
Federico

________________________________

Iscriviti alla nostra newsletter per rimanere aggiornato su digital ed email marketing! http://www.magnews.it/newsletter/

The information in this email is confidential and may be legally privileged. If you are not the intended recipient please notify the sender immediately and destroy this email. Any unauthorized, direct or indirect, disclosure, copying, storage, distribution or other use is strictly forbidden.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Mar 2017 04:21:10 -0400

> On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea <[email-masked]> wrote:
> 
> 

Keep it simple.  It is just as easy to block access to the TXT record as
to block access to the HTTPS site.  The TXT record is just an efficiency
aid, so that MTAs don't have to attempt costly HTTPS connections (that
typically time out) to domains with no STS records.

Therefore, when the TXT record exists, but STS policy access fails, the
right action is to assume no policy (regardless of whether this is a
true first contact, or whether a previously cached policy had expired).

STS is vulnerable to attack when no cached policy exists.  Once the
cache is primed, email to destinations that receive ongoing traffic
will continue to have unexpired policy data, because the sender
should do proactive refresh of the policy before it expires.

For first contact, or domains that don't receive sufficiently regular
mail, STS is vulnerable to downgrade attacks.

So the right behaviour with TXT records that don't lead to a policy,
is to continue as though there is no policy.

Indeed with Postfix (if/when STS is implemented) I'm likely to
always do STS policy lookup in the background, in which case
the first (more than one if concurrent) message(s) to a domain
will always go out with opportunistic TLS, and secure delivery
will only begin once the background policy retrieval succeeds.

Delaying delivery while waiting for remote HTTPS lookups to
complete is not especially appealing.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 27 Mar 2017 13:41:05 +0200

I like your text, Federico:

I will get this into the latest draft. :) (This was previously implied
anyway by the fact that a failure to find a policy means there's no policy,
but it's not so clear as you make it with this edit.)

Regarding the threat of DoS'ing policy lookup until expiration has passed,
as Viktor notes, this is party mitigated by opportunistically fetching new
policies every so often (e.g. when delivering to the domain); Viktor has
previously suggested we call this out more explicitly in the draft (i.e.
that we suggest implementors seek some strategy to keep caches fresh).

In this scenario, I do still feel that there's some gap in a mechanism
(say, via TLSRPT) to allow senders who have non-expired policies from a
recipient domain to tell the recipient domain that they're having trouble
fetching that domain's policy, but the solution is not obvious to me and, I
think, of a lower priority--if you can DoS policy lookup for order of
months, you can potentially foil first discovery, too. And ultimately
long-lived DoSes are the kinds of things to best be discovered through
other transparency and reporting tools--https://gmail.com/postmaster/,
discussions on the IETF list, etc. ;)

Anyway, I'm very open to suggestions on how to make this more transparent
within the scope of TLSRPT, but I don't love the idea of adding policy
complexity by letting recipients specify what to do in this scenario.

On Mon, Mar 27, 2017 at 10:21 AM, Viktor Dukhovni <[email-masked]>
wrote:

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Mar 2017 08:05:55 -0700

> typically time out) to domains with no STS records.
Actually, it's easier to block access to the TXT record, because it's
obvious in the clear that it's an MTA-STS TXT record, and an MITM that
is actively interfering with STARTTLS would likely be able to block
retrieval of the TXT record. In contrast, it's probably harder to block
the HTTPS site without potentially causing collateral damage.

The TXT record is more than an efficiency aid if clocking it causes the
policy not to be discovered at all. OTOH, if it is used just to discover
policy updates, we wouldn't have that problem. But that would increase
the traffic load on the HTTPS server considerably.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Mar 2017 11:17:32 -0400

> On Mar 27, 2017, at 11:05 AM, Jim Fenton <[email-masked]> wrote:
> 
> The TXT record is more than an efficiency aid if cloaking it causes the

The phrase "the HTTPS server" hides an important assumption, namely
that there is an HTTPS server in the first place.  For the majority
of domains there will (for some time) be no STS policies, and no
secure way to discover whether there should be a server or not.

Publishing an STS policy is not a requirement for SMTP, so STS
discovery is opportunistic, and for lack of DNSSEC vulnerable
to downgrades.

The cacheable TXT record is an efficient mechanism for signalling
when to try to load a (new?) policy.

If we did not want to signal expedited updates by changing the id,
the signal could be just the existence of an A record for some
"reserved" hostname in the domain, but that also runs into the issue
that reserved hostnames are not a good idea or popular at the IETF.

-- 
-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 27 Mar 2017 22:42:13 +0200

I'm also not convinced that it is harder to block the HTTPS request, since
the hostname there is not the nexthop domain but is itself a special
hostname ("mta-sts"). Given that, an attacker who can block the TXT can
just block the CNAME/A/AAAA record for "mta-sts".

You'd have to get rid of that and host the .well-known path at the naked
domain (or something innocuous, like www) for that to not work (without the
risk of noticeable side effects), and that has serious downsides in other
ways.

That said, while I'm not sure this focus is incorrect, it is worth
restating that for many cases--notably, for large hosts who cannot easily
deploy DNSSEC because of unrelated constrains--the primary defense against
persistent refresh blocking will be transparency, in the form of reports
(like Postmaster Tools), person-to-person contact, etc.

(To analogize very slightly to a mostly different context, the same
argument applies to provide some justification for "unsafe" defaults on,
say, WhatsApp end-to-end encryption: while key-exchange MITMs are
possible--a sort of spiritually similar attack to the policy discovery
attack here--as long as some people are turning on key validation some of
the time, any *widespread* MITM is likely to be discovered, posing a
substantial risk to bulk interception.)

---

From: Federico Santandrea <[email-masked]>
Date: Tue, 28 Mar 2017 12:18:08 +0200

From Security Considerations section of draft-ietf-uta-mta-sts-03:

    "Similarly, we consider the possibilty of domains that deliberately
    allow untrusted users to serve untrusted content on user-specified
    subdomains.  In some cases (e.g. the service Tumblr.com) this takes
    the form of providing HTTPS hosting of user-registered subdomains
     [...] In these cases, there is a risk that untrusted users would be
    able to serve custom content at the "mta-sts" host, including
    serving an illegitimate SMTP STS policy."

It's likely that such domains serve wildcard certificates for
user-specified subdomains. I think a further mitigation of this could
be to require the HTTPS connection's certificate to be valid precisely
for the mta-sts.example.com host, ignoring wildcard matches.

-- 
Federico

---

From: Federico Santandrea <[email-masked]>
Date: Tue, 28 Mar 2017 12:38:26 +0200

On 27/03/2017 13:41, Daniel Margolis wrote:
> Anyway, I'm very open to suggestions on how to make this more
> transparent within the scope of TLSRPT, but I don't love the idea of
>  adding policy complexity by letting recipients specify what to do in
>  this scenario.

To allow the receiving domain owner to spot abnormal situations without
complicating the report, we could add semantics to the date-range.

The draft says:

    o  "date-time": The date-time indicates the start- and end-times for
       the report range.  It is provided as a string formatted according
       to Section 5.6, "Internet Date/Time Format", of [RFC3339].  The
       report should be for a full UTC day, 0000-2400.

If we replace that with something along the lines of:

    o  "date-time": The date-time indicates the start- and end-times for
       the report range.  It is provided as a string formatted according
       to Section 5.6, "Internet Date/Time Format", of [RFC3339].
       "start-datetime" should be 0000 UTC of the relevant day or the
       first time a policy was discovered, whichever comes last.
       "end-datetime" should be 2400 UTC of the relevant day or the
       time the last cached policy did expire, whichever comes first.

Then one would normally see reports for one whole day, except when one
first publishes a policy and in abnormal situations where a policy
has been allowed to expire with no new one available.

In that case it will be clear that for some part of the day no policy
was considered, which can be expected (if the domain doesn't publish a
policy anymore) or unexpected (network problems/attacks on the sending
MTA or, if the problem is widespread across senders, possible
misconfiguration of denial of service on records or endpoints).

If in the same day a policy is discovered again after a previous one
has expired, then we would have more than one report for that day:
for instance, one from 0000 to the time the policy had expired, and
another one from the time a new policy had been discovered to 2400.
So the gap during which no policy applied would be evident.

-- 
Federico

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 28 Mar 2017 18:25:36 +0200

Yes, I think we have discussed the possibility of that before. You could
also do this with a new EKU value, I think. Ultimately the value of adding
this constraint is unclear to me; for example, dyndns.org would not be
saved by that (since a user who has "foo.dyndns.org" can easily get a cert
for that name); conversely, it could make it harder for some people to
adopt (I guess). So I Don't know.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 28 Mar 2017 18:26:54 +0200

Of course a smart attacker who can MITM insecure DNS can spoof reports (and
optionally MITM the DKIM lookup to make the reports look valid). So it's
sort of turtles all th way down, no?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Mar 2017 12:48:11 -0400

> On Mar 28, 2017, at 6:38 AM, Federico Santandrea <[email-masked]> wrote:
> 

Not just when first publishing, but also when each new sending
system first discovers a policy, which will make for too much
noise in the reports.

Also, policy expiration will not be "abnormal".  If I implement
STS, pre-expiration background policy refresh will not happen
in the absence of email to the destination domain.  This avoids
unbounded fiiling of the cache with junk domains to which email
delivery has long ceased.

The simplest solution is to accept that STS covers ongoing
validation of email to frequently used domains, and is otherwise
subject to downgrade.

-- 
	Viktor.