Subject: [Uta] Warren Kumari's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS)

From: Warren Kumari <[email-masked]>
Date: Thu, 10 May 2018 07:41:05 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-uta-mta-sts-17: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ Edit: Could the format of the _mta-sts to be something like:
"_mta-sts.example.com.  TXT "v=STSv2; id=20180114T070707; label=foo"  ?

This would mean that the policy can be fetched from foo.example.com - the
record *could* specify "label=mta-sts" if it wanted - this allows this to work
without "reserving" a DNS label.  ]

I apologize, this DISCUSS written in a rush.

I'm uncomfortable with the DNS "reservations" happening in this document -- it
basically reserves the (leftmost) DNS labels _mta-sts (as a TXT record) and
mta-sts as a hard-coded name -- I think that this needs to be better documented
/ in the IANA considerations.

I apologize for the lack of detail/lack of actionable content - I couldn't
decide between Deferring and balloting DISCUSS -- I decided on DISCUSS because 
I think I need to think about this, and clearing a DISCUSS is simpler than
having the document stuck for a full cycle.

---

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

> On May 10, 2018, at 10:41 AM, Warren Kumari <[email-masked]> wrote:
> 

Absent DNSSEC (which is the sad reason that MTA-STS exists at all) the TXT
record is untrusted data, and so should likely not be able to redirect the
policy source to an arbitrary host in the domain.  I think that rather weakens
the security model...

-- 
	Viktor.

---

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

Right.

An attacker who can inject false DNS resolutions can, of course, redirect
either the fixed mta-sts host or insert a spoofed TXT response--but by
allowing the attacker to specify what hostname to use, it is more likely
that attacks which indirectly allow an attacker to obtain a valid cert for
a subdomain (as in the Tumblr or Blogspot case) can be leveraged (along
with DNS injection) to serve a spoofed policy for the whole domain.

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

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 10 May 2018 15:23:44 +0000

> with DNS injection) to serve a spoofed policy for the whole domain.

.. but isn't this also the case with the current solution?
 Unless Tumblr and Blogspot and everyone else know to reserve mta-sts, we
have a similar issue
​​
? We've seen issues in the past where people forget to "reserve" hostmaster@
and hostmaster@, etc , and hilarity ensues.
​

Setting a precedent of reserving DNS labels in this way scares me...

W​

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

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

> On May 10, 2018, at 11:23 AM, Warren Kumari <[email-masked]> wrote:
> 
>> An attacker who can inject false DNS resolutions can, of course, redirect either the fixed mta-sts host or insert a spoofed TXT response--but by allowing the attacker to specify what hostname to use, it is more likely that attacks which indirectly allow an attacker to obtain a valid cert for a subdomain (as in the Tumblr or Blogspot case) can be leveraged (along with DNS injection) to serve a spoofed policy for the whole domain. 
> 

Not so much.

>  Unless Tumblr and Blogspot and everyone else know to reserve mta-sts, we have a similar issue​​? We've seen issues in the past where people forget to "reserve" hostmaster@ and hostmaster@, etc , and hilarity ensues.​ 

The real concern is for domains that have MTA-STS policy. A forged
TXT record should not be able to redirect the policy to a different
source.  If a domain has no MTA-STS policy, then a failure to reserve
the mta-sts hostname might allow someone to register that subdomain,
but that someone would still to MiTM the TXT record, and they could
instead MiTM the MX records.

So all that "mta-sts" buys them is the ability to create an extended
DoS, until the domain owner takes over "mta-sts" and publishes a new
TXT record.  It's not great that the DoS could happen, but recovery
is just taking back control of the delegation.

That said, I share your concern about reserved hostnames.  The only
realistic alternative is to require "example.com" rather than
"mta-sts.example.com", which limits HTTPS hosting options.

MTA-STS is a kludge to avoid DNSSEC, and some contortions and caveats
are inevitable.

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 10 May 2018 21:05:54 +0000

On Thu, May 10, 2018 at 11:36 AM Viktor Dukhovni <[email-masked]>
wrote:

> >> An attacker who can inject false DNS resolutions can, of course,
> redirect either the fixed mta-sts host or insert a spoofed TXT
> response--but by allowing the attacker to specify what hostname to use, it
> is more likely that attacks which indirectly allow an attacker to obtain a
> valid cert for a subdomain (as in the Tumblr or Blogspot case) can be
> leveraged (along with DNS injection) to serve a spoofed policy for the
> whole domain.
> >
> >  Unless Tumblr and Blogspot and everyone else know to reserve mta-sts,
> we have a similar issue​​? We've seen issues in the past where people
> forget to "reserve" hostmaster@ and hostmaster@, etc , and hilarity
> ensues.​
>
​Yup -- ​this has (and please correct me if I'm wrong) the properties that:
1: people (systems) shouldn't resolve the mta-sts.example.com name without
the _mta-sts.example.com name telling them to.
2: this is "restrictive" - if I happen to be able serve something from
mta-sts.example.com I cannot "gain" any privileges or access - all I can do
is cause a DoS.

For #1, I get that the existence of the _mta-sts label *should* be the
signal that the mta-sts exists and means something... but you *know* some
programmers are lazy and will just attempt to fetch
https://mta-sts.example.com/.well-known/mta-sts.txt and see if it works.

For #2: if I happen to already have a machine called mta-sts.example.com
(e.g: Metro Transport Agency - Security Theatre System) or can cause a
webserver to have that name (mta-sts.blogspot.com) I cannot redirect mail,
"all" I can do is DoS mail (coupled with #1).

The fact that this is restrictive use case makes me less concerned, but I'm
scared about creating the pattern.
An example of when something similar to #2 caused issues (in a
non-restrictive case) are the cases where mail servers operators haven't
reserved e.g hostmaster@, someone has been able to get that as an email
address and then use that to get a DV cert, transfer the domain, etc.
Unless everyone knows that an identifier needs to be reserved, it can cause
entertainment...

I'm still deeply uncomfortable with reserving a label by fiat, but I think
that much of my concerns can be alleviated by adding some more text to the
document explaining *why* this approach was taken. Ie: why "_
mta-sts.example.com.  TXT "v=STSv2; id=20180114T070707; label=foo" isn't
affective -- I understand your security argument, but I think explaining
this in the document would be useful to prevent / minimize the precedence
setting.

I also think that someone, somewhere should write a document which creates
a registry for names like this -- AFAICT, this is the first time that we
would be doing something like this (for non-underscore names).
Dave Crocker has a draft with created an _underscore registry -
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/  - this
document should probably be added to that.

W

---

From: Ted Hardie <[email-masked]>
Date: Thu, 10 May 2018 14:39:30 -0700

Howdy,

After this morning's IESG conversation, I've been thinking about this some
more and, even with Viktor's comment, I think we have to describe this as a
convention rather than a reservation.  That is, I think we have to say that
to deploy this you need to control both the ability to generate a TXT
record with _mta-sts.example.com as a prefix and the hostname
mta-sts.example.com.  If you don't control both, you cannot deploy this.
Other registrations of mta-sts.example.com are still permitted, but unless
they are linked to that TXT record, those uses will not (and should not be
expected to) work to achieve the goals of this specification.  (If you do
control both and choose to deploy it, the spec as-is describes what to do).

I'm basing this in part on the conversations that went into the IDN
reservation of prefix (xn--), where nearly all the proponents agreed that
they could not guarantee that some human-friendly string was not in use by
an existing registration at some depth of the tree.  In order to avoid late
registrations into whatever string was chosen, the early discussions didn't
include the string at all; it was chosen by IANA at a very late stage.
mta-sts is sufficiently human friendly that I'm convinced that it is either
in use somewhere now or will eventually be, for some reason that registrant
will feel trumps this. Getting everyone to say "no" in the future might,
conceivably, be possible, even thought it will be.  If the registration is
already done, there is just no way to say "no" in the past.

I've also looked through a bunch of the earlier descriptive documents (e.g.
in the FYI series), and I think they describe conventions (nic.example.com,
mail.example.com) rather than making reservations.  Making a wholesale
reservation at all levels of the tree that might run mail services seems to
me to traipse into policy domains which the IETF has mostly farmed out.

The good news is that I don't think there is a practical difference for
those that want to deploy this; they still do the same thing.  The bad news
is that Warren's concern about that lazy programmer just checking the
mta-sts.example.com host without looking for the TXT record will eventually
turn into a security issue, but that will be bad code, not a bad
specification.

Just my take on it, of course,

Ted

On Thu, May 10, 2018 at 2:05 PM, Warren Kumari <[email-masked]> wrote:

> 1: people (systems) shouldn't resolve the mta-sts.example.com name
> without the _mta-sts.example.com name telling them to.
> mta-sts.example.com I cannot "gain" any privileges or access - all I can
> do is cause a DoS.
>
> webserver to have that name (mta-sts.blogspot.com) I cannot redirect
> mail, "all" I can do is DoS mail (coupled with #1).
>
> The fact that this is restrictive use case makes me less concerned, but
> I'm scared about creating the pattern.
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 10 May 2018 18:07:01 -0400

> On May 10, 2018, at 5:39 PM, Ted Hardie <[email-masked]> wrote:
> 
> The good news is that I don't think there is a practical difference for those that want to deploy this; they still do the same thing.  The bad news is that Warren's concern about that lazy programmer just checking the mta-sts.example.com host without looking for the TXT record will eventually turn into a security issue, but that will be bad code, not a bad specification.

What might help is that not many lazy programmers get to write MTA
implementations, particularly with fancy bells and whistles like
MTA-STS.  They're more likely to write SUBMIT clients, which are
not in scope for this specification.

And thus, indeed "mta-sts.example.com" has no special meaning unless
the TXT record is also present.

So this feature of the spec is somewhat unfortunate, but perhaps
the right tradeoff vs. limiting deployment to domains that are
able to serve the policy from "https://example.com".   Folks
operating organizational websites can speak more to how much
of a burden such a constraint might be.

-- 
	Viktor.

---

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

I also want to point out (in regards to Warren's comment) that someone who
controls mta-sts.example.com *and can inject the _mta-sts TXT record* can
only redirect mail insofar as they could do so otherwise--because they will
still need to tamper with the MX records, and tampering with MX records
(absent DNSSEC, which prevents the whole thing) allows redirection of mail
*absent* STS. So in general we introduce no extra risk on mail *redirection* so
much as a risk of sustained DoS: my biggest fear with the whole scheme was
creating an opportunity for attackers to serve a policy that bounces
legitimate mail, and that less than savvy admins would have trouble
revoking that policy. However, since that requires a magical TXT record
(assuming no lazy implementations!), that attacker who can write to the DNS
zone can probably also inject an MX record with a long TTL--not quite the
same thing, but somewhat similar. (These concerns are discussed similarly
in Security Considerations.)

I agree this is a convention and not a reservation, to Ted's point.

On Fri, May 11, 2018 at 12:07 AM Viktor Dukhovni <[email-masked]>
wrote:

> mta-sts.example.com host without looking for the TXT record will
> eventually turn into a security issue, but that will be bad code, not a bad
> specification.
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 May 2018 15:04:05 -0400

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

> MTA-STS.

​Yup, I was more concerned about this becoming a pattern with gets copied
and reused in other protocols, and then it comes back to bite us...​

> They're more likely to write SUBMIT clients, which are

I *suspect* that people won't like this; serving anything from a naked
domain makes me twitch, but a: I'm old fashioned and b: it seems that all
the cool kids are doing it,​ so I may be wrong. Actually, does anyone know
of a "major" site which *doesn't* serve something (even if it is just a
redirect) from just the naked domain?

W

--

---

From: Warren Kumari <[email-masked]>
Date: Fri, 11 May 2018 15:04:31 -0400

On Fri, May 11, 2018 at 6:16 AM Daniel Margolis <[email-masked]>
wrote:

> *absent* STS. So in general we introduce no extra risk on mail
> *redirection* so much as a risk of sustained DoS: my biggest fear with
> the whole scheme was creating an opportunity for attackers to serve a
> policy that bounces legitimate mail, and that less than savvy admins would
> have trouble revoking that policy. However, since that requires a magical
> TXT record (assuming no lazy implementations!), that attacker who can write
> to the DNS zone can probably also inject an MX record with a long TTL--not
> quite the same thing, but somewhat similar. (These concerns are discussed
> similarly in Security Considerations.)
>

​Ok. Would you be able to craft some text around that?
W​

---

From: Daniel Margolis <[email-masked]>
Date: Sun, 13 May 2018 17:36:34 +0200

This is quite similar to the existing language in Section 10.3. Does that
suffice as-is?

On Fri, May 11, 2018 at 9:05 PM Warren Kumari <[email-masked]> wrote:

>> I also want to point out (in regards to Warren's comment) that someone
>> who controls mta-sts.example.com *and can inject the _mta-sts TXT record* can
>>> > The good news is that I don't think there is a practical difference
>>> for those that want to deploy this; they still do the same thing.  The bad
>>> news is that Warren's concern about that lazy programmer just checking the

---

From: Adam Roach <[email-masked]>
Date: Sun, 13 May 2018 11:17:47 -0500

> instead MiTM the MX records.

Right. It's the fact that anyone who can replace the TXT record could 
also replace the MX record that, I think, undermines the argument about 
sending MTAs to the wrong STS policy server. I don't see an attack here 
that is more powerful than other attacks that someone with the same 
capabilities could launch.

/a

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 14 May 2018 11:15:48 +0200

Just to make sure I understand, your point was that there's no additional
risk introduced by having arbitrary hostnames for the Policy Host, and
having the hostname specified via the TXT record?

I tend to agree about the security reasoning (i.e., that having the TXT
provide indirection to the Policy Host introduces no real risks), but I
think it may still be easier, operationally, to have this be fixed. I think
the only real concern I would have is if this has any operational costs: if
that special hostname is for some reason already being used in a way which
is incompatible with our usage.

FWIW, I have a list of 205k mail domains that Viktor gave me, of which zero
have an A record for "mta-sts.$domain" (at least when I did a lookup just
now). So my guess is that this is not very likely to be already in use, and
the simplicity is worth it. Is that reasonable? Objections? I admit this is
a handwavy argument. ;)

Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 May 2018 12:08:36 +0000

On May 14, 2018, at 5:15 AM, Daniel Margolis <[email-masked]> wrote:

> I tend to agree about the security reasoning (i.e., that having
> the TXT provide indirection to the Policy Host introduces no real
> risks),

Allowing the TXT record do specify the authority domain of
the MTA-STS policy URL would allow any party in control of
some HTTPS endpoint in the domain to forge the domain's MTA-STS
policy, provided they are able to MiTM the lookup of the TXT
record.  I think this needlessly weakens MTA-STS security.

So I don't think we have the option of a dynamic policy URL 
authority.  It is either "mta-sts.example.com" (or some similar 
name) or just "example.com" (zone apex with no "conventional" 
label prefix).

-- 
	Viktor.

P.S.  As to the 205k domains, they are all DNSSEC-signed have
DANE-enabled MX hosts, and are all direct (one label) sub-domains
of a public suffix list domain.  Some organizations have email
addresses in sub-domains, I don't track any of those.  And many
of the 205k domains with MX hosts at the large providers are
parked.

A more representative survey might be the domains published in
Gmail's transparency report, with the scope possibly expanded to
include more domains that receive less mail than the cut-off for
making that list.

I still would not expect to find "mta-sts" used outside the
early pilot domains for this draft.

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 May 2018 11:03:18 -0500

> record.  I think this needlessly weakens MTA-STS security.

The point is: that same person could install an MX record that points to 
an (out-of-domain) MTA that they control, which implements whatever 
policy they want, and then forwards mail to the real MTA in a way that 
complies with the original policy. Clearly they're in a position to do 
far more than violating STS policy, but if that's what they're after, 
there's a clear path.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 14 May 2018 11:05:45 -0500

On 5/14/18 4:15 AM, Daniel Margolis wrote:
> FWIW, I have a list of 205k mail domains that Viktor gave me, of which 
> zero have an A record for "mta-sts.$domain" (at least when I did a 
> lookup just now). So my guess is that this is not very likely to be 
> already in use, and the simplicity is worth it. Is that reasonable? 
> Objections? I admit this is a handwavy argument. ;)

It's not really about this specific name as much as it is the 
generalized reservation of names all over the DNS tree. As Warren points 
out, if we're going to start doing that kind of thing, we really need to 
have a registry to avoid collisions; and we really need to consider 
whether that's the right approach in general.

/a

---

From: James Cloos <[email-masked]>
Date: Mon, 14 May 2018 12:26:24 -0400

>>>>> Viktor Dukhovni <[email-masked]> writes:

> name) or just "example.com" (zone apex with no "conventional" 

If there is any concern with using mta-sts, there is no good reason to
avoid using no prefix at all.

The concept of using www for web sites was never beneficial, and even if
there is a simple redirect, excluding /.well-known/mta-sts.txt from that
and serving a simple static file is not a difficult task.

Using a prefix for the txt rr has value, but using a prefix for the a rr
does not.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 14 May 2018 19:41:21 +0200

I don't understand either of these comments.

The TXT record could only safely be used to select the host (i.e. the
in-zone name) for the policy URL, not the fully qualified domain, so I
don't think it introduces the weakness Viktor supposes.

Similarly, the policy host must be in the zone of the recipient domain, so
it does not allow the attack you describe, either, Adam. The policy is for
the recipient domain (i.e. after the @ sign), not the MX domain.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 May 2018 13:54:16 -0400

> On May 14, 2018, at 1:41 PM, Daniel Margolis <[email-masked]> wrote:
> 
> The TXT record could only safely be used to select the host (i.e. the in-zone name) for the policy URL, not the fully qualified domain, so I don't think it introduces the weakness Viktor supposes.

Yes, I was well aware that the name would have to share a suffix with the
policy domain.  And yet, there is still a problem if there are any names
in policy the domain that are controlled by customers, rather than the parent
organization.  I don't think that an insecurely vended policy authority (even
within the policy domain) is a good idea.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 15 May 2018 15:30:19 +0200

Put slightly differently, allowing TXT-based indirection can at best be as
secure as the current design, and at worse introduce some unknown
vulnerability (depending on DNS architecture for a zone, etc). So I think
that's really the main reason we wanted to keep it fixed.

In all likelihood it does not introduce a vulnerability nor does it
introduce operational issues for anyone, but, valid concerns about
"reserved" (even if just by convention) names notwithstanding, I'd rather
accept any operational risks that poses than take the risk of a
vulnerability. So I think you and I are on the same page here.

Anyway, in the short run, there *is* at least the .well-known registry to
ensure the full URI is reserved; in the long run I thought I recalled
someone was looking into a registry for "reserved" DNS names. (But from the
perspective of STS, if someone else uses "mta-sts" for anything else, it
doesn't really affect the operation of the system.)

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 May 2018 09:40:50 -0400

> On May 15, 2018, at 9:30 AM, Daniel Margolis <[email-masked]> wrote:
> 
>  I'd rather accept any operational risks that poses than take the risk of a vulnerability. So I think you and I are on the same page here.

yes.

-- 
	Viktor.

---

From: [email-masked]
Date: Tue, 15 May 2018 07:51:33 -0700 (PDT)

> that's really the main reason we wanted to keep it fixed.

Given the ability to redirect, there's going to be a temptation to piggyback
the handing out of mta-sts policies on some existing web service. It's unlikely
that doing this will result in a security win.

> vulnerability. So I think you and I are on the same page here.

Since what's reserved is a single URI, not the domain, a conflicting use of the
domain actually reduces to a service combination scenario similar to what
indirection can lead to.

However, I think the liklihood of a domain conflict is a hell of a lot smaller
than the liklihood of administrators over-optimizing things, so independent of
the possibiltiy of a vulnerability we're not seeing, not allowing indirection
seems to be the better operational approach.

> doesn't really affect the operation of the system.)

Exactly. And I think we can safely ignore the possibility of there
being a URI conflict.

				Ned

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 May 2018 11:28:33 +0200

On Tue, May 15, 2018 at 3:30 PM Daniel Margolis <[email-masked]>
wrote:

> Put slightly differently, allowing TXT-based indirection can at best be
as secure as the current design, and at worse introduce some unknown
vulnerability (depending on DNS architecture for a zone, etc). So I think
that's really the main reason we wanted to keep it fixed.

> Anyway, in the short run, there is at least the .well-known registry to

Yup, there is no current registry for "reserved" DNS names -- there is a
registry for reserved Special Use Domain Names (
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml),
Locally Served DNS Zones (
https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml),
and Dave Crocker is working on a registry for underscore names (
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/) -- we
don't have a registry for "reserved" DNS names, and that is the root of my
concern - if we did, we could just toss this in, and we'd be golden --
instead, we have names which are used *by convention* --- I've been
noodling on text to explain that "by convention the name is at
mat-sts.example.com", but I haven't been able to come up with text that
doesn't sound contrived at best, or disingenuous at worst.

W