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

From: Jim Fenton <[email-masked]>
Date: Tue, 21 Feb 2017 15:55:54 -0800

Below are comments from my recent reading of draft-ietf-uta-mta-sts-03.

The biggest concern I have is the relationship between the DNS TXT
record and the HTTPS policy record. The policy is hosted in HTTPS rather
directly in DNS in order to attempt to provide security without DNSSEC.
But if attacks on DNS are in the threat model, one has to consider that
an attacker might make it appear that there is not a DNS TXT record at
all, which causes the HTTPS record not to be retrieved at all (MTA STS
is presumed not to be deployed). This makes MTA STS too easy to defeat.

=====

Abstract

Introduces the acronym for the specification as SMTP STS. Should
probably be MTA STS. Is MTA STS hyphenated? Document is inconsistent.

1.0 Introduction

"...delete parts of the SMTP session..." -> "...delete or corrupt parts
of the SMTP session..." (in view of common firewall behavior to change
STARTTLS to XXXXXXXX).

"...downgrade or interception attacks..." -> "...downgrade or MITM
attacks..." (interception is the motive or result, not the attack).

2.0. Related Technologies

"In addition, SMTP STS provides..." -> "In addition, MTA STS
provides..." (and elsewhere in the document)

3.0. Policy Discovery

If an attacker is able to spoof an NXDOMAIN response to the TXT record
request, MTA STS is ignored. This seems like a pretty serious problem in
the absence of DNSSEC, the use of which is of course not being assumed.

3.1. MTA-STS TXT records

There is no IANA registry for reserved hostnames, which is why protocols
like SPF store their policies at the domain itself. Is there some reason
this is not being done here? The version field can be used to
distinguish from SPF records and other TXT records at the domain level.

"...are discarded" -> "...MUST be discarded"

3.2. MTA-STS Policies

"mx": Why is there an emphasis on providing confirmation of the response
to the MX lookup, when it is just as easy to spoof the A/AAAA record
lookup that follows the MX and yet there is no publication of an A/AAAA
policy?

"A lenient parser SHOULD accept...": For the protocol to be extensible,
this has to be "Parsers MUST accept..."

"...SHALL be ignored" -> "...MUST be ignored"

3.3. HTTPS Policy Fetching

Why MUST 3xx redirects not be followed?

"A suggested timeout is one minute..." This could quickly tie up SMTP
client resources. Is there any mitigation for that? It also seems like a
long timeout.

4.2. MX Certificate Validation

Is there a way to allow either CA-based validation or DANE for a
certificate that is presented? This seems to conflict with the use of
DANE-based certificate validation, or at least there is no order of
precedence for certificate validation.

5.0. Policy Application

"When a message fails to deliver...": How does the check for the updated
policy occur, by looking for an updated TXT record or by re-retrieving
the HTTPS policy?

5.2. Policy Application Control Flow

In step 1, it is not clear whether the attempt to fetch a new policy
involves the TXT record or directly the HTTPS policy.

In step 2, should some sort of warning be generated if the retrieved
MXes differ from the current policy, or is this considered normal? It
might be a sign of spoofing or misconfiguration.

6.1. Policy Updates

"...HTTPS endpoint has been updated but the TXT record has not yet
been...": Throughout this specification, no mention is made of DNS
caching of the TXT records. Should the records be published with
relatively short TTL, or relatively long TTL? It definitely has an
effect on how dynamic the domain's policy can be.

8. Security Considerations

Item 2, falsification of A/AAAA responses can also be used to redirect
client connections to a rogue server.

"Sender policy cache": It's not clear how this resists the blockage of
the TXT record. If the record is consistently blocked, the policy will
never be discovered to be cached. Also, caches are of finite size and
can not be expected to be kept consistently. If a client discovers a
policy with serial number "xxx", and then subsequently doesn't discover
a policy through the TXT record, what does it do?

Malicious MTA-STS TXT record: This seems to assume that the motive of
the attacker is to create a rogue MX server, but suppose the motive of
the attacker is instead to foil reception of email by the domain. Could
they accomplish this by publishing a bogus STS policy that makes all the
MX records look bad? This relates to the problem of not having an IANA
host name registry.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 23 Feb 2017 23:01:18 +0200

Hey, thanks for the feedback. Comments inline.

> is presumed not to be deployed). This makes MTA STS too easy to defeat.

I don't believe I can speak to this with authority, but I feel somewhat
comfortable excluding an *ever-present* active MITM from our threat model.
It's certainly trivial to defeat initial policy discovery, but an attacker
must do this all the time. It's feasible, but there's some probability of
discovery, of course.

> probably be MTA STS. Is MTA STS hyphenated? Document is inconsistent.

Thanks, good point. We originally used "SMTP STS" and at some point
switched, apparently imperfectly. Sigh. ;)

> distinguish from SPF records and other TXT records at the domain level.

This is reasonable, but note that we still require the special hostname for
the HTTPS host (necessary since some domains will not want to host the
HTTPS endpoint at the top-level); reusing it for the TXT record seems
reasonable, no? I'm not wedded to this, but I would avoid unnecessary
changes unless there's a good reason at this point. Is the risks of
collision with a pre-existing record high? I would think not.

(I'm lazy here because we already have various code that refers to this
record name, and already changed it between version 2 and version 3 of the
draft...)

> lookup that follows the MX and yet there is no publication of an A/AAAA

The "mx" constraint isn't really about the hostnames (though of course it
is applied to them); it's about the subject of the server certificates
presented by the MX. A different (albeit, I think, needlessly confusing!)
design could allow for the MX hostnames to be arbitrary and not match the
"mx" constraint in any way; all that matters is the certificate name, for
exactly the reason you give.

> Why MUST 3xx redirects not be followed?

This was an arbitrary choice to avoid confusion. If we allowed the
following of redirects, is a policy behind an HTTPS redirect to a different
domain valid? What about to a non-HTTPS endpoint?

On the flip side, redirects allow easy delegation of policy hosting without
SNI--I could serve a 302 to "https://policy.myisp.net" on "
mta-sts.mydomain.com". If people think the latter is compelling, I'm open
to it, but we should have a good answer to the questions I posed above
about which redirect targets are valid.

> client resources. Is there any mitigation for that? It also seems like a

We discussed timeouts quite a bit here previously, I think. One minute
seemed reasonable to me in the context of
https://www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to it. That
said, it seems to me from that RFC that a standards-compliant message
delivery can (end-to-end) take substantially longer than 1 minute, if I am
reading correctly.

> precedence for certificate validation.

As you probably remember, we did try to have an "either/or" kind of
arrangement in the initial draft. It was a lot of extra complexity, I
think, for little gain--MTA-STS with DANE certificate validation is sort of
pointless, since DANE implies DNSSEC, which implies MX records are
themselves signed.

> policy occur, by looking for an updated TXT record or by re-retrieving

By looking for an updated TXT record, as per section 3--but your question
suggests we should clarify this. ;)

> involves the TXT record or directly the HTTPS policy.

Yep, as above, I think.

> might be a sign of spoofing or misconfiguration.

See also David's comment and my reply under the thread "Updated drafts for
MTA-STS & TLSRPT."

We could leverage TLSRPT to report such cases, or force a check for a new
policy, or both, I think. Thoughts?

> effect on how dynamic the domain's policy can be.

To restate your comment, if one anticipates publishing breaking new
policies, then one must account for the lifetime of cached TXT records.

So if one plans to do so in the near future, one should probably choose a
short TTL. It's reasonable for us to call this out, I Think.

> a policy through the TXT record, what does it do?

Honor the cache. If a valid override of a cached policy is not found, a
compliant sender must honor the cached policy.

> MX records look bad? This relates to the problem of not having an IANA

Only if they can host a policy on a HTTPS endpoint. We note the denial of
service risk as well in this section, and some of the mitigations.

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Feb 2017 13:46:16 -0800

On 02/23/2017 01:01 PM, Daniel Margolis wrote:
> On Wed, Feb 22, 2017 at 1:55 AM, Jim Fenton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> I don't believe I can speak to this with authority, but I feel
> somewhat comfortable excluding an /ever-present/ active MITM from our
> threat model. It's certainly trivial to defeat initial policy
> discovery, but an attacker must do this all the time. It's feasible,
> but there's some probability of discovery, of course.

It's not that the attack has to be ever-present, it's that client MTAs
that don't have a cached policy for the recipient domain will be showing
up all the time, and will need to retrieve the policy. To the extent
that they don't get the TXT record on the first try, they will infer
that there is no policy, and will continue to do so while the negative
response is cached by their responder (minimum TTL, typically only a few
minutes, but the SOA in the NXDOMAIN response could also be spoofed to
make this much longer). This waters down the effectiveness of MTA STS.

> This is reasonable, but note that we still require the special
> hostname for the HTTPS host (necessary since some domains will not
> want to host the HTTPS endpoint at the top-level); reusing it for the
> TXT record seems reasonable, no? I'm not wedded to this, but I would
> avoid unnecessary changes unless there's a good reason at this point.
> Is the risks of collision with a pre-existing record high? I would
> think not. 
>
> (I'm lazy here because we already have various code that refers to
> this record name, and already changed it between version 2 and version
> 3 of the draft...)

It looks like the _ may be coming back as a result of the CNAME problem
noted on the other discussion thread. But the point is that IETF/IANA
have consistently declined to register specific hostnames for specific
purposes -- not even www. for the Web -- and I don't see why an
exception would be made now.

> The "mx" constraint isn't really about the hostnames (though of course
> it is applied to them); it's about the subject of the server
> certificates presented by the MX. A different (albeit, I think,
> needlessly confusing!) design could allow for the MX hostnames to be
> arbitrary and not match the "mx" constraint in any way; all that
> matters is the certificate name, for exactly the reason you give.

Fair enough -- the certificate name addresses the A/AAAA issue.

> following of redirects, is a policy behind an HTTPS redirect to a
> different domain valid? What about to a non-HTTPS endpoint? 
>
> On the flip side, redirects allow easy delegation of policy hosting
> without SNI--I could serve a 302 to "https://policy.myisp.net" on
> "mta-sts.mydomain.com <http://mta-sts.mydomain.com>". If people think
> the latter is compelling, I'm open to it, but we should have a good
> answer to the questions I posed above about which redirect targets are
> valid.

I was mostly asking that there be some explanation of the "no 3xx"
thing. Unless it introduces a definite security vulnerability, it's
worth considering whether there are email use cases that would be easier
to set up. You could potentially just prohibit redirect to non-HTTPS,
although a non-HTTPS policy might still be better than nothing.
> seemed reasonable to me in the context
> of https://www.ietf.org/rfc/rfc2821.txt, but I'm not really wedded to
> it. That said, it seems to me from that RFC that a standards-compliant
> message delivery can (end-to-end) take substantially longer than 1
> minute, if I am reading correctly.

Rather than (or in addition to) a specific value, it might be better to
have some guidelines on choosing the proper value in various situations.

> think, for little gain--MTA-STS with DANE certificate validation is
> sort of pointless, since DANE implies DNSSEC, which implies MX records
> are themselves signed.

So what takes precedence: if there is a DANE policy, is MTA-STS ignored?

> By looking for an updated TXT record, as per section 3--but your
> question suggests we should clarify this. ;)

Yes, but Viktor's observation on the other thread (that TXT record
lookups are cheap) applies here so maybe just start all the flows with a
TXT record lookup.

> See also David's comment and my reply under the thread "Updated drafts
> for MTA-STS & TLSRPT." 
>
> We could leverage TLSRPT to report such cases, or force a check for a
> new policy, or both, I think. Thoughts?

Will get into this once I have had a chance to review TLSRPT.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Feb 2017 02:49:18 +0000

> make this much longer). This waters down the effectiveness of MTA STS.

This is a fundamental limitation of STS.  STS cannot protect first
contact.  There is no reasonable way to design around this.  If
you want downgrade resistance, deploy DANE.

> Fair enough -- the certificate name addresses the A/AAAA issue.

Indeed constraining the names in the certificate is exactly how
mandatory TLS policy works in Postfix.  We don't filter the MX
hostnames, rather the destination policy can filter the acceptable
certificate names regardless of the MX hostname.

    http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match

Filtering the MX hostnames is an indirect way of solving the same
underlying problem.  Perhaps "mx" should be renamed to "san" and
MX host selection then completely decouples from the security
policy.  When the connection is to a host whose certificate is not
suitable, the client hangs up and tries another MX host (up to
whatever limits on the number of such attempts are applicable).

Since this simplifies the protocol, and reduces the code changes
needed in MTAs, it is worth considering.

> So what takes precedence: if there is a DANE policy, is MTA-STS ignored?

A sane client that supports DANE should prefer DANE when TLSA
records are published by the destination.  This is based on the
stronger downgrade resistance of DANE and no requirement for
long-term local storage.  Policy lookups have costs, and once a
DANE policy is found, it is simplest to not even bother looking
for STS policy.

Clients that want to eke out as much security as possible might
support both, and use DANE when possible and otherwise STS when
possible.

> >     "When a message fails to deliver...": How does the check for the
> >     updated policy occur, by looking for an updated TXT record or by
> >     re-retrieving the HTTPS policy?
> >

I am sticking with that position.

-- 
	Viktor.

---

From: Alberto Bertogli <[email-masked]>
Date: Tue, 28 Feb 2017 21:02:18 +0000

> record name, and already changed it between version 2 and version 3 of the

For what is worth, as one of the persons who suggested the removal of
the "_" previously (and I'm sorry I didn't realize the problem with the
CNAMEs!), having the TXT at the top level sounds nice to me, pretty much
for the same reasons mentioned before (makes deployment easier).

It has the additional nicety that SPF and friends are also expected to
be at the top level too.  None of this is crucial, but anyway :)

Thanks!
		Alberto

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2017 04:55:22 -0000

In article <[email-masked]> you write:
>like SPF store their policies at the domain itself.

Urrgh.  SPF is as far as I know the only protocol published by the
IETF that stores policies at the unprefixed hostname, and that is
widely agreed to be a mistake.  DKIM and DMARC use prefixes.

There's the somewhat separate issue that if the prefixed name has to
be a hostname so it can be used in a URI, it can't contain an
underscore.

R's,
John

PS: Dave Crocker and I have been working on a prefix registry, but
it's a thankless task.