I'm also not convinced that it is harder to block the HTTPS request, since
the hostname there is not the nexthop domain but is itself a special
hostname ("mta-sts"). Given that, an attacker who can block the TXT can
just block the CNAME/A/AAAA record for "mta-sts".You'd have to get rid of that and host the .well-known path at the naked domain (or something innocuous, like www) for that to not work (without the risk of noticeable side effects), and that has serious downsides in other ways. That said, while I'm not sure this focus is incorrect, it is worth restating that for many cases--notably, for large hosts who cannot easily deploy DNSSEC because of unrelated constrains--the primary defense against persistent refresh blocking will be transparency, in the form of reports (like Postmaster Tools), person-to-person contact, etc. (To analogize very slightly to a mostly different context, the same argument applies to provide some justification for "unsafe" defaults on, say, WhatsApp end-to-end encryption: while key-exchange MITMs are possible--a sort of spiritually similar attack to the policy discovery attack here--as long as some people are turning on key validation some of the time, any *widespread* MITM is likely to be discovered, posing a substantial risk to bulk interception.) On Mon, Mar 27, 2017 at 5:17 PM, Viktor Dukhovni <[email protected]> wrote: > > > On Mar 27, 2017, at 11:05 AM, Jim Fenton <[email protected]> wrote: > > > > The TXT record is more than an efficiency aid if cloaking it causes the > > policy not to be discovered at all. OTOH, if it is used just to discover > > policy updates, we wouldn't have that problem. But that would increase > > the traffic load on the HTTPS server considerably. > > The phrase "the HTTPS server" hides an important assumption, namely > that there is an HTTPS server in the first place. For the majority > of domains there will (for some time) be no STS policies, and no > secure way to discover whether there should be a server or not. > > Publishing an STS policy is not a requirement for SMTP, so STS > discovery is opportunistic, and for lack of DNSSEC vulnerable > to downgrades. > > The cacheable TXT record is an efficient mechanism for signalling > when to try to load a (new?) policy. > > If we did not want to signal expedited updates by changing the id, > the signal could be just the existence of an A record for some > "reserved" hostname in the domain, but that also runs into the issue > that reserved hostnames are not a good idea or popular at the IETF. > > -- > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
