Subject: Re: [Uta] Updated MTA-STS & TLSRPT

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Oct 2017 20:43:36 +0000

On Sat, Sep 30, 2017 at 11:15:45AM +0200, Daniel Margolis wrote:

> Regarding caching, Viktor, Binu, do you believe this is useful to allow?

I think it is useful.

> While it can be done safely (by simply ensuring the cache-control headers
> set by the mta-sts.provider.com host--i.e. the one behind the proxy--are
> "correct"), it doesn't strike me as necessary; perhaps it's simpler and
> safer to simply recommend against HTTP caching. The expected request rate
> is low, and I would assume any provider behind the proxy can handle more
> traffic than the proxy itself, so caching isn't quite as compelling, no?

The provider can likely handle the query rate just fine, but serving
cached content is much cheaper than making upstream connections to
the provider.  So I think this is attractive for the site doing the
delegation.

-- 
	Viktor.

---

From: Binu Ramakrishnan <[email-masked]>
Date: Mon, 2 Oct 2017 21:58:34 +0000 (UTC)

My preference would be not to cache the policy by the reverse-proxy. Like Dan said, the provider can handle more traffic than the proxy, hence I think caching is not a requirement. Provider may set appropriate Cache-Control HTTP header to prevent caching
Example:Cache-Control: no-cache, no-store, must-revalidate

If caching is desired, then provider may set a Cache-Control policy with an short TTL. The proxy may cache the policy until the cache expires. 
Thanks,-binu
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

      From: Viktor Dukhovni <[email-masked]>
 To: [email-masked] 
 Sent: Monday, 2 October 2017 1:43 PM
 Subject: Re: [Uta] Updated MTA-STS & TLSRPT

I think it is useful.

-- 
    Viktor.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Oct 2017 22:15:20 +0000

On Mon, Oct 02, 2017 at 09:58:34PM +0000, Binu Ramakrishnan wrote:

> My preference would be not to cache the policy by the reverse-proxy. Like
> Dan said, the provider can handle more traffic than the proxy, hence I
> think caching is not a requirement.

The provider may not require it, but it is useful for the provider's
customer.  You may be too used to the provider's point of view. :-)

> Provider may set appropriate
> Cache-Control HTTP header to prevent caching

I think that's too strict.  After all, policies will be cached by
MTAs for weeks or months.  So allowing them to be cached for a few
minutes by a reverse proxy makes good sense.

> If caching is desired, then provider may set a Cache-Control policy with
> an short TTL. The proxy may cache the policy until the cache expires. 

That'd be the advice I'd like to see in the draft.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 3 Oct 2017 11:04:19 +0200

Yes, if we are going to allow cache-control, I think we should call it out
explicitly.

But this feels a bit weird to me: we are going to say that cache-control
headers may be honored by proxies but not by MTA clients fetching the
policy for their own use? Why do that?

If someone might conceivably proxy your policy, then you really want to get
your cache-control headers right. At which point you may as well allow MTAs
to use them, too.

In any event, I believe the main argument against cache-control is merely
that it means deployers (i.e. policy domains) have to be aware of it--they
must consider, e.g. in section 6.3, that a policy will be valid for "last
serve time + max age *+ cache ttl*". This isn't especially complex, but I
think it's the primary simplicity argument against HTTP caching.

In any event, like I said, if we want to allow cache-control, we should
just allow it globally. It's not horrible to allow it, but we should be
consistent. No?

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Oct 2017 12:54:48 -0400

> On Oct 3, 2017, at 5:04 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Yes, if we are going to allow cache-control, I think we should call it out explicitly.

I don't like to see under-specified features in a protocol.  So yes!

> But this feels a bit weird to me: we are going to say that cache-control headers may be honored by proxies but not by MTA clients fetching the policy for their own use? Why do that?

Well MTAs are not Web browsers or HTTP proxies, so they don't go around caching
HTTP content as such.  They will cache MTA-STS *policies* in some appropriate
internal representation of said policies, with a cache lifetime that is no greater
than the policy "max_age" field.  Therefore, cache-control is of no possible
relevance to the MTA.

Given that the MTA is accessing an HTTPS URL, even if it were configured to use a
(forward) HTTPS proxy to access the Web, it would use "CONNECT" to establish an
HTTPS tunnel, and so any proxy cache is typically bypassed.  Only when the proxy
is doing MITM SSL interception (mints certificates for remote sites on the fly via
a CA cert trusted by the MTA) is there a possibility of caching in the proxy, but
I would expect that SSL MITM proxies are not really in the caching business...

So I think that cache control is simply not applicable to the MTA, and there's
no need to "prohibit" it as such.

> If someone might conceivably proxy your policy, then you really want to get your cache-control headers right. At which point you may as well allow MTAs to use them, too.

See above.  I don't see how or why the MTA would use said cache-control headers.

> In any event, I believe the main argument against cache-control is merely that it means deployers (i.e. policy domains) have to be aware of it--they must consider, e.g. in section 6.3, that a policy will be valid for "last serve time + max age + cache ttl". This isn't especially complex, but I think it's the primary simplicity argument against HTTP caching.

The cache TTL should be short enough to be inconsequential by comparison with "max age", and yet long enough to allow a reverse proxy to consolidate closely-spaced requests.  Anything more than 60s is probably counter-productive until we start hosting SMTP server farms on Mars.

> In any event, like I said, if we want to allow cache-control, we should just allow it globally. It's not horrible to allow it, but we should be consistent. No?

See above, it is not that prohibiting processing of HTTP cache control headers
by SMTP servers was needed, but rather than this specification explicitly
overrides any such headers with "max_age", which is intended to be an explicit
part of the policy and not some out of band data managed in the HTTP server
configuration.

The explicit presence of "max_age" makes possible and *invites* the possibility
of using a shorter cache-control lifetime for use-cases like reverse proxies.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 4 Oct 2017 17:39:14 +0200

> no need to "prohibit" it as such.

I mean, I agree that it's unlikely an MTA would *want* to do this, but I
think it's useful that we (already have) said "no honoring
cache-control"--the implication of not saying that is that someone who
wants to can cache the HTTP content for up to the cache lifetime, which
may, in some bizarre (and probably faulty) misconfiguration be longer than
the max_age, thus resulting in a cache hit on policy refresh, which is
silly. (Even if it's not longer than max_age, a DNS- or failure-triggered
policy refresh could hit the HTTP cache.)

So I agree that MTAs are unlikely to want to honor HTTP caching headers,
but my point was more that they really *shouldn't* do so, since HTTP
caching brings more complexity to the system and, quite possibly, heartache
and tears. In the interests of specifying the protocol clearly, we just
forbid it.

> > In any event, I believe the main argument against cache-control is
> merely that it means deployers (i.e. policy domains) have to be aware of
> it--they must consider, e.g. in section 6.3, that a policy will be valid
> for "last serve time + max age + cache ttl". This isn't especially complex,
> but I think it's the primary simplicity argument against HTTP caching.
>
> The cache TTL should be short enough to be inconsequential by comparison
> with "max age", and yet long enough to allow a reverse proxy to consolidate
> closely-spaced requests.  Anything more than 60s is probably
> counter-productive until we start hosting SMTP server farms on Mars.
>

I hear Elon Musk is working on that last one.

Are you suggesting we just say that cache-control can be honored up to a
value of 60s? I think that's fine. But note (as I said above) that caching
that is less than the max-age can still be problematic; it means that
someone who sees updated DNS but an old cached HTTP endpoint sees the old
policy. So the interplay between HTTP caching and DNS TTLs are weird, no?

> of using a shorter cache-control lifetime for use-cases like reverse

OK. So to be clear, is your suggestion just to allow cache-control headers *as
long as the cache lifetime is less than the policy max_age*? Or up to a
value of 60s? Or something else?

I think there is some oddity around cache lifetimes greater than the DNS
TTL, though...should we worry about that? Or just advise against it on the
grounds that it can result in confusion, but leave it up to deployers if
they wish to do it?

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Oct 2017 08:25:42 +0200

As usual I'm going to suggest that somebody comes up with specific
language we can discuss to keep the document moving towards completion
more quickly.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Oct 2017 07:40:25 +0000

On Wed, Oct 04, 2017 at 05:39:14PM +0200, Daniel Margolis wrote:

> > So I think that cache control is simply not applicable to the MTA, and
> > there's no need to "prohibit" it as such.
> 
> cache-control".

Agreed, we should keep on saying "no honoring cache-control" for
the MTA, however redundant that may be in practice.

> value of 60s? I think that's fine.

I was thinking that larger values should generally not be published,
but I am open to some client-side (reverse-proxy) limits if you think
that's appropriate.

> But note (as I said above) that caching

Good point, after updating the HTTPS policy, one MUST wait at least
the duration of the cache-ttl, before making visible DNS changes.
The same also applies when HTTPS changes are made in some content
management system and take a bit of time to propagate out to the
entire server farm.  The idea is to ensure that the most recent
visible change in the DNS id occurs more recently than the most
recent visible change in the underlying policy.

> value of 60s? Or something else?

Something on the order of 60s feels about right to me, it could be
even shorter.  Basically, anything that allows a reverse proxy to
consolidate a high-volume streamm of closely-spaced requests is
useful, and once it is only doing one upstream request every few
seconds, most of the gain is achieved.  There's little benefit to
pushing it to one upstream request every ten minutes or every hour.

So I guess I'd like to see providers offer a cache-ttl of at least
5s and at most 60s, with the latter limit recommended to be enfoced
by the reverse proxy as an upper bound.  The proxy MUST start the
clock from when it *initiates* the upstream connection, not when
it receives the payload, as network delays could otherwise lead to
serving stale data for fresh requests.

A related issue arises for MTAs, if two separate threads are doing
policy retrieval, it would be bad if policy data obtained by one
"thread" that took a long time to arrive displaced more recent data
obtained by another "thread".  And worse if the MTA fails to reliably
associate the TXT id that caused each thread to run with the policy
retrieved by that thread.  That is, it would be bad to squirrel
away the latest observed DNS TXT id in some shared state and then
separately obtain a policy, and at that time associate the policy
with a TXT id that may be a later one obtained by some other thread.

There needs to be a proper causal ordering of policy data and TXT
ids, where an MTA never ends up a TXT id with a policy that was
already replaced when the TXT id was published.

> grounds that it can result in confusion, but leave it up to deployers if

I don't think that's an issue, provide the TXT id is never visible
before the new policy is in place, and the old has been flushed
from any HTTP caches.  When TXT TTL expires, the client will just
go fetch the latest.  Seeing a slightly stale TXT is never a problem,
what could be a problem is seeing a stale policy in association with
a fresh TXT.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 5 Oct 2017 09:52:47 +0200

Well, so this isn't that big a change or that weird, and I think we can
mostly reconcile here. :)

In section 3.3, we already say this:

   Senders may wish to rate-limit the frequency of attempts to fetch the
   HTTPS endpoint even if a valid TXT record for the recipient domain
   exists.  In the case that the HTTPS GET fails, we suggest
   implementions may limit further attempts to a period of five minutes
   or longer per version ID, to avoid overwhelming resource-constrained
   recipients with cascading failures.

So we are already opening the door to short-term caching-*like* behavior in
some cases, for basically the reasons you describe (throttling, though in
the section 3.3. case, to avoid repeatedly hitting an endpoint in case of
*failure*).

First, we all agree MTAs should not use HTTP caching, since it's redundant
and confusing.

If we want to allow intermediate proxies to use HTTP caching, they should
do so only if the cache-control headers allow it, or else their behavior
will be opaque to the real server.

The real server, if it allows HTTP caching, should probably not allow
caching of any meaningful period of time--say, 1 minute--and should
probably in practice make the cache lifetime much shorter than the DNS TTL,
since the caching then becomes mostly immaterial. (I'm fudging a bit here,
but it makes operational considerations easier: the HTTP cache lifetime is
fetch-time + cache lifetime, whereas the DNS cache lifetime is resolve-time
+ TTL; since resolve-time and fetch-time are quite close together, making
the DNS TTL longer than the HTTP cache lifetime removes the need to
seriously consider the HTTP caching.)

As Lief said, what's the concrete language here?

"HTTP caching MAY be used by reverse proxies if allowed by the
Cache-Control headers on the HTTPS endpoint. Hosts who are serving a policy
that is delegated to by other domains SHOULD limit their cache lifetimes to
values under one minute; further, when rotating deployed policies, they
should consider that the new HTTP policy may not be visible to MTAs
fetching the delegator domain's policy until the HTTP cache lifetime has
expired."

Something like that?

---

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 9 Oct 2017 18:24:36 +0000

Do we think we really need to allow caching?  From what are we trying to protect the backend systems?  Feels like it would be easier to disallow caching (or recommend against).  I understand the sense that a smaller company could be overwhelmed by an attacker or ill-configured legit sender, but I don’t know how much caching will really help there.  The caching server would be similarly overwhelmed I would imagine, and be unable to serve policies to any other requesting systems.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

From: Uta [mailto:[email-masked]] On Behalf Of Daniel Margolis
Sent: Thursday, October 05, 2017 3:53 AM
To: [email-masked]
Subject: Re: [Uta] Updated MTA-STS & TLSRPT

Well, so this isn't that big a change or that weird, and I think we can mostly reconcile here. :)

   recipients with cascading failures.
So we are already opening the door to short-term caching-*like* behavior in some cases, for basically the reasons you describe (throttling, though in the section 3.3. case, to avoid repeatedly hitting an endpoint in case of *failure*).

First, we all agree MTAs should not use HTTP caching, since it's redundant and confusing.

If we want to allow intermediate proxies to use HTTP caching, they should do so only if the cache-control headers allow it, or else their behavior will be opaque to the real server.

The real server, if it allows HTTP caching, should probably not allow caching of any meaningful period of time--say, 1 minute--and should probably in practice make the cache lifetime much shorter than the DNS TTL, since the caching then becomes mostly immaterial. (I'm fudging a bit here, but it makes operational considerations easier: the HTTP cache lifetime is fetch-time + cache lifetime, whereas the DNS cache lifetime is resolve-time + TTL; since resolve-time and fetch-time are quite close together, making the DNS TTL longer than the HTTP cache lifetime removes the need to seriously consider the HTTP caching.)

"HTTP caching MAY be used by reverse proxies if allowed by the Cache-Control headers on the HTTPS endpoint. Hosts who are serving a policy that is delegated to by other domains SHOULD limit their cache lifetimes to values under one minute; further, when rotating deployed policies, they should consider that the new HTTP policy may not be visible to MTAs fetching the delegator domain's policy until the HTTP cache lifetime has expired."

Something like that?

On Thu, Oct 5, 2017 at 9:40 AM, Viktor Dukhovni <[email-masked]<mailto:[email-masked]>> wrote:

--
        Viktor.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Oct 2017 19:54:35 +0000

On Mon, Oct 09, 2017 at 06:24:36PM +0000, Brotman, Alexander wrote:

> Do we think we really need to allow caching?  From what are we trying to
> protect the backend systems?

NOT the backend systems, rather the rather more constrained reverse
proxies of the customers.

Caching can of course be disabled by provider, but I think that's
needless inconsiderate of the reverse proxies.

> Feels like it would be easier to disallow
> caching (or recommend against).  I understand the sense that a smaller
> company could be overwhelmed by an attacker or ill-configured legit sender,
> but I don�t know how much caching will really help there.  The caching
> server would be similarly overwhelmed I would imagine, and be unable to
> serve policies to any other requesting systems.

The defense is not against deliberate DDoS, rather it significally
reduces proxy concurrency, by making it possible to serve content
from a cache, rather than go upstream for each request.  This
can significantly improve scalability at little cost.

All the provider has to do is delay the publication of the TXT
record, until the corresponding new policy has been the only
one available for > 60s.  This is a low cost to pay, and allows
cooperative caching to be supported by providers that wish to
do so.  I think that providers should support caching, but
this specification will not require them to do so.

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 9 Oct 2017 20:58:36 +0000

The points are valid.  I suppose I just expect that the tiny file will reside in memory and require little to serve it (beyond as you stated, initiating a session), resulting in little benefit.  Just seems like we're stating something that could/should be left to the implementer/admin at the site to implement as is proper for their environment.

I believe Daniel was waiting on comments from Leif (and Viktor?)about his proposed language changes.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Monday, October 09, 2017 3:55 PM
To: [email-masked]
Subject: Re: [Uta] Updated MTA-STS & TLSRPT

On Mon, Oct 09, 2017 at 06:24:36PM +0000, Brotman, Alexander wrote:

> Do we think we really need to allow caching?  From what are we trying 
> to protect the backend systems?

NOT the backend systems, rather the rather more constrained reverse proxies of the customers.

Caching can of course be disabled by provider, but I think that's needless inconsiderate of the reverse proxies.

> Feels like it would be easier to disallow caching (or recommend 
> against).  I understand the sense that a smaller company could be 
> overwhelmed by an attacker or ill-configured legit sender, but I don t 
> know how much caching will really help there.  The caching server 
> would be similarly overwhelmed I would imagine, and be unable to serve 
> policies to any other requesting systems.

The defense is not against deliberate DDoS, rather it significally reduces proxy concurrency, by making it possible to serve content from a cache, rather than go upstream for each request.  This can significantly improve scalability at little cost.

All the provider has to do is delay the publication of the TXT record, until the corresponding new policy has been the only one available for > 60s.  This is a low cost to pay, and allows cooperative caching to be supported by providers that wish to do so.  I think that providers should support caching, but this specification will not require them to do so.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Oct 2017 22:14:45 +0000

On Mon, Oct 09, 2017 at 08:58:36PM +0000, Brotman, Alexander wrote:

> The points are valid.  I suppose I just expect that the tiny file will
> reside in memory and require little to serve it (beyond as you stated,
> initiating a session),

The "initiatig a session" cost is precisely the cost that caching
helps to avoid.  Any request rate faster than 1/min becomes ~1/min
when a 60/s cache is enabled.

> resulting in little benefit.  

I disagree there.

> Just seems like we're
> stating something that could/should be left to the implementer/admin at
> the site to implement as is proper for their environment.

The request is to NOT prohibit caching between the reverse proxy and
the provider, and to give said provider some guidance on pitfalls to
avoid.

Daniel's proposal looked on track to me.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 10 Oct 2017 11:03:03 +0200

> Daniel's proposal looked on track to me.

If nobody else has an opposing view I'd say rev the document with the
proposed change and lets call it a day.