Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

[Daniel Margolis <[e-mail]>]

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 <[e-mail]>
wrote:

>
> > On Mar 27, 2017, at 11:05 AM, Jim Fenton <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>