Subject: Re: [Uta] review of mta-sts-01

From: Daniel Margolis <[email-masked]>
Date: Thu, 1 Sep 2016 09:27:54 +0200

Right. I understood you, but that was my question--I don't see any reason
to remove hosts at worse preference from any invalid hosts, but only to
remove those at worse preference from the current host to avoid loops. In a
non-looping case, it's sufficient for the sending MTA to simply skip any
hosts that are invalid and do whatever it would otherwise do (including
using hosts of lower priority than the invalid ones).

Seems like we agree on this.

On Wed, Aug 31, 2016 at 4:57 PM, Viktor Dukhovni <[email-masked]>
wrote:

>
> > On Aug 31, 2016, at 10:00 AM, Daniel Margolis <[email-masked]>
> wrote:
> >
> >> My suggestion would be that non-matching MX hosts and any MX hosts with
> a worse (higher) MX preference
> >> be removed from the MX RRset, leaving only matching hosts at an equal
> or better (lower) preference.  Mail
> >> delivery can proceed only if that set is non-empty.  If a first
> matching MX host fails authentication, then
> >> a second matching MX host is tried, ... until one passes, all are
> tried, or some sender limit on the number
> >> of MX hosts to try is reached.  Mail is deferred if none of the
> attempted MX hosts pass authentication.
> >
> > Not to be stupid, but why eliminate hosts with a higher preference than
> the matching MX? It seems like they would still be valid candidate MXes in
> the failure case.
>
> Perhaps I was not sufficiently clear, I was suggesting removal
> of MX hosts at a worse preference than any non-matching host.
>
> On second thought it would be sufficient for hosts (as usual)
> to first eliminate all MX entries at an equal or worse preference
> to any entry that matches themselves (by name or address), and
> only then check which (remaining) MX host comply with STS policy.
>
> The goal is to ensure that no loops result if an MX host applies
> the STS filter first, and fails to remove other hosts at an equal
> or worse priority.
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 1 Sep 2016 03:57:33 -0400

> On Sep 1, 2016, at 3:27 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Right. I understood you, but that was my question--I don't see any reason to remove hosts at worse preference from any invalid hosts, but only to remove those at worse preference from the current host to avoid loops. In a non-looping case, it's sufficient for the sending MTA to simply skip any hosts that are invalid and do whatever it would otherwise do (including using hosts of lower priority than the invalid ones). 

The mistake to avoid is removal of hosts deemed invalid by STS *prior*
to checking whether the current host is one of those.  That is, loop
elimination first, and only then STS policy on the remaining host.

Perhaps this seems obvious, but it is I think worth stating.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 1 Sep 2016 13:09:52 +0200

Agreed, that's a sort of subtle bug that's worth calling out. Thanks for
that.

On Thu, Sep 1, 2016 at 9:57 AM, Viktor Dukhovni <[email-masked]>
wrote:

> > Right. I understood you, but that was my question--I don't see any
> reason to remove hosts at worse preference from any invalid hosts, but only
> to remove those at worse preference from the current host to avoid loops.
> In a non-looping case, it's sufficient for the sending MTA to simply skip
> any hosts that are invalid and do whatever it would otherwise do (including

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 02 Sep 2016 14:42:11 +0000

On Tue, Aug 9, 2016 at 4:49 PM Stephen Farrell <[email-masked]>
wrote:

>
> - 3.3: I forget why "policy.mta-sts" is what's prepended to the
> policy domain. Personally, I dislike the two-level thing there
> and don't see that it's useful. If you do keep it, then it'd be
> good to justify it. But that's mostly a matter of taste I
> think. OTOH, it might be a small barrier to deployments in some
> places, not sure.
>
>
The rationale here was that it's far more likely that someone gives
untrusted users the ability to host untrusted content on a hostname of
their choosing than on a sub-zone. E.g. tumblr.com, dyndns.org, etc, have
the concern of someone registering "mta-sts.tumblr.com", but you can't (on
those platforms) register "policy.mta-sts.tumblr.com", to my knowledge.

This does make things a tad uglier, though, and I think it may even make it
harder for some people to publish a policy with an existing wildcard
certificate (e.g. *.example.com would not match).

So I think it's worth getting feedback from the group on that tradeoff. Any
opinions here?

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Sep 2016 15:45:00 +0100

> So I think it's worth getting feedback from the group on that tradeoff. Any

I'd argue to ditch the two-level thing and go to one,
e.g. "mta-sts.example.com" or whatever string you like
for that hostname.

S

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2016 16:36:26 -0000

>e.g. "mta-sts.example.com" or whatever string you like

You might want to pass that by dnsop and see how much heartburn a
reserved hostname is going to cause.

For this application, I don't see any alternative since there
are apparently too many systems that haven't been upgraded
since SRV was introduced 20 (yes really) years ago.

But I can promise you there will be pushback and not ridiculous
suggestions that since this is a new service and it is exactly the
sort of thing that SRV was invented for, use it.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Sep 2016 17:00:11 +0000

> sort of thing that SRV was invented for, use it.

SRV cannot be used here, because presumptively DNSSEC is not in
use, and thus the client's reference identifier for the STS policy
server must be deterministically constructed from the nexthop
domain.  

I had suggested the simpler approach of using the domain itself
with no prefix, but apparently folks don't want to have to tie this
service to the zone apex.

So some sort of fixed prefix seems unavoidable.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2016 17:52:10 -0000

>server must be deterministically constructed from the nexthop

So how about if we put in a note saying that the host that the SRV
points to better be a subdomain of the original, or clients are going
to be reluctant to believe it.

Yes, that's still a kludge, but it's doesn't cause the mandatory
collisions that a reserved hostname does.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Sep 2016 20:18:04 +0000

> collisions that a reserved hostname does.

That runs afoul of the need to not delegate policy to untrusted
nodes somewhere in one's own domain tree.  Some service operators
dole-out leaf nodes to "strangers".  Universities may delegate
sub-domains to deparments, that might employ their dedicated IT
staff that are not trusted by the parent organization, ...

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2016 20:29:38 -0000

>staff that are not trusted by the parent organization, ...

So you're saying that if the hostname is hard coded, you somehow know
it's not delegated to someone else, but if it comes from a SRV record,
you don't?  

This really strikes me as looking for trouble.  If your system is so
poorly run that the people who are operating your subdomains are
attacking your main domain, you have worse problems than STS can
solve.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Sep 2016 23:27:10 +0000

> it's not delegated to someone else, but if it comes from a SRV record,

I expect that for domains that actually have an STS policy, I can
rely on a downgrade resistant access path to that policy.

For example an on-path attacker might redirect the SRV record to
some HTTPS server which does not publish an STS policy (404), and
that should mean that the policy has been revoked.

Or one might find some sub-domain with a weak policy and direct
the client there (which might be somewhat addresed by including
the domain name in the policy).

Or indeed, when strangers can register sub-domains, the SRV with
a constrant to a subdomain model breaks down.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 6 Sep 2016 22:25:55 +0200

I may be missing something, but surely anything an attacker can do to a SRV
record they can do to a CNAME or A record for a host itself. So hardcoding
the hostname itself doesn't do much against attackers who can arbitrarily
inject DNS records. (The defense here is really in the SSL cert validation
and the assumption that nobody is serving untrusted content on
.well-known/...)

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Sep 2016 20:45:40 +0000

On Tue, Sep 06, 2016 at 10:25:55PM +0200, Daniel Margolis wrote:

> record they can do to a CNAME or A record for a host itself.

Generally, with SRV records, one would expect that the reference
identifier for certificate name checks is the target hostname, not
the service domain.

Note also that the nexthop domain itself (example.com vs.
mta-sts.example.com or similar) typically operates multiple https
services, many of which would deny (404) the existence of the STS
policy resource, and thus clear the policy cache.

> So hardcoding the hostname itself doesn't do much against attackers who
> can arbitrarily inject DNS records. (The defense here is really in the
> SSL cert validation and the assumption that nobody is serving untrusted
> content on .well-known/...)

It is not that simple.  The target URI has be verifiably the right
URI for STS policy lookup, not just some random web service associated
with the domain.

Furthermore, STS is subject downgrade attacks via MITM redirection
to unintended HTTPS servers that have a wildcard cert for the
domain, and so the STS spec may need to specifically forbid wildcard
certificate matching.

A bad alternative is to not support authenticated policy revocation
via a 404 response, treating that as a transient lookup error, but
this is not a good outcome.  You might need to extend the spec to
support serving an explicit policy revocation response.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 7 Sep 2016 11:46:33 +0200

If we forbid wildcards, the argument against the two level hostname goes
away. That is, the only argument against "policy.mta-sts" is that it breaks
"example.com" wildcards! I think there's a reasonable argument for going
that direction, as you say, though, hence my question for input here. Do we
prefer to make deployment and cert reuse easy at slight risk of attacks as
described?

Regarding 404s (a slight tangent now), I am not sure we do want to treat
that as revocation. To me, a 404 runs a somewhat higher risk of operational
mix-ups, and revocation can be had more explicitly but serving a policy
with a very short max-age (which we could make explicit, i.e. "max-age of
zero equals revocation").

---

From: Mark Risher <[email-masked]>
Date: Wed, 7 Sep 2016 07:47:35 -0700

It feels like allowing wildcards will help with adoption, because web
domains [that use them] can then reuse their existing certificates for
STARTTLS. Deployment and cert reuse are essential to making progress;
creating key-management challenges for small companies will mean that
traffic continues in the clear.

I agree that 404 should be a soft fail for the reasons you listed, Dan.

/m

--
Mark E. Risher |   [email-masked] |  650-253-3123

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Sep 2016 10:57:54 -0400

> On Sep 7, 2016, at 10:47 AM, Mark Risher <[email-masked]> wrote:
> 
> It feels like allowing wildcards will help with adoption, because web domains [that use them] can then reuse their existing certificates for STARTTLS. Deployment and cert reuse are essential to making progress; creating key-management challenges for small companies will mean that traffic continues in the clear. 
> 

If 404 is a soft fail, and maxage=0 is revocation, what should a sending MTA
do when it encounters a 404 (or indeed an HTTPS connection timeout, handshake
failure, ...)?  Retry the HTTPS policy lookup on every delivery?  Employ some
sort of hold-down timer between soft-failed lookups?  How should the hold-down
be chosen?

My preference is to not have to hammer away at broken or misconfigured the
HTTPS servers with every message delivery, that can have a big effect on SMTP
delivery latency and thereby throughput.

Returning to John Levine's suggestion of SRV records, what should the reference
identifier (and SNI value) be in that case?  If it is the SRC record target host,
should any sub-domain (at any depth) of the nexthop domain be admissible if that
becomes the reference identifier?  Or must the target host present a certificate
that exactly matches the original service (nexthop) domain?

I think some language that nails this down is needed in the spec.  Please
discuss.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 7 Sep 2016 18:56:53 +0200

> sort of hold-down timer between soft-failed lookups?  How should the

My point was that a 404 could be treated the same as a DNS lookup failure.
Admittedly, it need not be so; 404s are of course signed implicitly if
delivered over HTTPS. But because of the operational concerns I outlined, I
had thought it made more sense to treat them however we treat DNS
resolution failures.

(In particular, I believe we specify that if a new, valid policy cannot be
found, the cached policy should be used. So in the case of a 404 we would
temp-fail and so forth.)

> delivery latency and thereby throughput.

The only time it results in that is also if the cached policy is invalid.
That is to say, the possibilities are:

Sender has cached policy: Y/N
Cached policy validates the MX: Y/N

If the above is Y/Y, the sender can merely deliver. If the above is Y/N,
the sender should not deliver. If the above is N/_, the sender can deliver,
same as for any other domain missing a policy. Regardless of the result of
a new policy fetch, that applies (so long as the cached policy is not
expired).

No?

> I think some language that nails this down is needed in the spec.  Please

Well, only if we go with SRV records. Which (as you describe) seems to
expand the complexity slightly. I think this can (of course) be done
without any security misses, but I'm not sure it's preferable to the
hardcoded hostname.

That said, I don't want to poo-poo anyone's ideas of a nice zonefile. ;)
Maybe we should bite the bullet and use SRV, but I'd like to hear some
strong consensus for that before I try to write the language for it.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Sep 2016 17:52:25 +0000

On Wed, Sep 07, 2016 at 06:56:53PM +0200, Daniel Margolis wrote:

> > HTTPS servers with every message delivery, that can have a big effect on
> > SMTP delivery latency and thereby throughput.
> 

You're forgetting the DNS refresh trigger, which does not invalidate
the cached policy, but signals a need to attempt to refresh.

If the DNS policy id differs from the cached value, the client
is expected to update the policy, if it tempfails to obtain the
fresh policy, how often should it retry?

> > Returning to John Levine's suggestion of SRV records, what should the
> > reference identifier (and SNI value) be in that case?  If it is the SRV
> > record target host, should any sub-domain (at any depth) of the nexthop
> > domain be admissible if that becomes the reference identifier?  Or must
> > the target host present a certificate that exactly matches the original
> > service (nexthop) domain? > I think some language that nails this down is
> > needed in the spec.  Please discuss.
>

I'll leave expanding on the importance of that point to John.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 7 Sep 2016 22:16:12 +0200

> fresh policy, how often should it retry?

I don't think there's currently any language which actually requires the
sender to temp-fail if they can't get a new policy despite the DNS
indicator indicating they should--only that they must get a new policy upon
a validation failure. So if the DNS refresh trigger says "refresh me!" but
the old policy works, I think a compliant sender can safely simply deliver
with the old policy. Is there a reason we would want to do otherwise?
(Given that the DNS indicator has no security guarantee, we can't really
rely on it working, after all...)

Regardless, is this different than handling any other temp-fail?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Sep 2016 16:40:26 -0400

> On Sep 7, 2016, at 4:16 PM, Daniel Margolis <[email-masked]> wrote:
> 
> I don't think there's currently any language which actually requires the sender to temp-fail if they can't get a new policy despite the DNS indicator indicating they should--only that they must get a new policy upon a validation failure. So if the DNS refresh trigger says "refresh me!" but the old policy works, I think a compliant sender can safely simply deliver with the old policy. Is there a reason we would want to do otherwise? (Given that the DNS indicator has no security guarantee, we can't really rely on it working, after all...)

I've not made myself clear, when I said temp-fail, that was just the
HTTPS refresh, indeed the SMTP message goes on its merry way with the
cached policy, but because we (temp)failed to refresh the HTTPS policy,
we'll have to keep trying, so long as the DNS record signals a policy
change.

Therefore we can be in a state in which the DNS record signals a need
for HTTPS refresh, which tempfails repeatedly for a possibly long time.
During that time, it would be bad to make policy refresh attempts 1:1
for every message delivery.  Should the spec advise a hold-down strategy.

The options are:

   * Say nothing, leave implementations to do as they see fit.

   * Suggest a minimum hold-down time of say 30 minutes (or whatever)
     between refresh attempts.

   * Let the originally retrieved policy publish a retry time
     (as with DNS SOA records) that applies on failure.  The SOA's model of refresh/retry/expire may well
     be quite applicable).

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 7 Sep 2016 23:27:00 +0200

Ah, sorry. Yes, I agree with you here.

I would be inclined to make a suggestion that implementors think about this
possibility and that careful implementors may reasonably want to limit
attempts to less than once every n minutes. If my previous observations
about RFC mandated timeouts are any guide, implementors will sort of go do
their own thing anyway, so I don't think we should bother to *mandate* anything
specific; conversely, it doesn't seem to me that recipients really benefit
from having a knob to turn on the retry frequency, so this doesn't really
need to be specified per-policy.

"A careful implementation may wish to limit the number of refresh attempts
in the case that the TXT record indicates a refreshed policy is available
but the HTTPS fetch fails for any reason. We suggest implementations may
limit these attempts to a period of five minutes or longer per version ID."

Or something. Reasonable?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Sep 2016 21:37:53 +0000

> Or something. Reasonable?

Likely close enough, unless others feel that recipient policy should
give receiving sites the flexibility to signal preferred
refresh/retry/expire timers (the current spec already specifies
expire, and refresh is signalled out of band via DNS, so perhaps
an implementation selected retry is good enough.

-- 
	Viktor.