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 protected]] On Behalf Of Viktor Dukhovni Sent: Monday, October 09, 2017 3:55 PM To: [email protected] 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. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
