Howdy, After this morning's IESG conversation, I've been thinking about this some more and, even with Viktor's comment, I think we have to describe this as a convention rather than a reservation. That is, I think we have to say that to deploy this you need to control both the ability to generate a TXT record with _mta-sts.example.com as a prefix and the hostname mta-sts.example.com. If you don't control both, you cannot deploy this. Other registrations of mta-sts.example.com are still permitted, but unless they are linked to that TXT record, those uses will not (and should not be expected to) work to achieve the goals of this specification. (If you do control both and choose to deploy it, the spec as-is describes what to do).
I'm basing this in part on the conversations that went into the IDN reservation of prefix (xn--), where nearly all the proponents agreed that they could not guarantee that some human-friendly string was not in use by an existing registration at some depth of the tree. In order to avoid late registrations into whatever string was chosen, the early discussions didn't include the string at all; it was chosen by IANA at a very late stage. mta-sts is sufficiently human friendly that I'm convinced that it is either in use somewhere now or will eventually be, for some reason that registrant will feel trumps this. Getting everyone to say "no" in the future might, conceivably, be possible, even thought it will be. If the registration is already done, there is just no way to say "no" in the past. I've also looked through a bunch of the earlier descriptive documents (e.g. in the FYI series), and I think they describe conventions (nic.example.com, mail.example.com) rather than making reservations. Making a wholesale reservation at all levels of the tree that might run mail services seems to me to traipse into policy domains which the IETF has mostly farmed out. The good news is that I don't think there is a practical difference for those that want to deploy this; they still do the same thing. The bad news is that Warren's concern about that lazy programmer just checking the mta-sts.example.com host without looking for the TXT record will eventually turn into a security issue, but that will be bad code, not a bad specification. Just my take on it, of course, Ted On Thu, May 10, 2018 at 2:05 PM, Warren Kumari <war...@kumari.net> wrote: > > > On Thu, May 10, 2018 at 11:36 AM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> >> >> > On May 10, 2018, at 11:23 AM, Warren Kumari <war...@kumari.net> wrote: >> > >> >> An attacker who can inject false DNS resolutions can, of course, >> redirect either the fixed mta-sts host or insert a spoofed TXT >> response--but by allowing the attacker to specify what hostname to use, it >> is more likely that attacks which indirectly allow an attacker to obtain a >> valid cert for a subdomain (as in the Tumblr or Blogspot case) can be >> leveraged (along with DNS injection) to serve a spoofed policy for the >> whole domain. >> > >> > .. but isn't this also the case with the current solution? >> >> Not so much. >> >> > Unless Tumblr and Blogspot and everyone else know to reserve mta-sts, >> we have a similar issue? We've seen issues in the past where people >> forget to "reserve" hostmaster@ and hostmaster@, etc , and hilarity >> ensues. >> >> The real concern is for domains that have MTA-STS policy. A forged >> TXT record should not be able to redirect the policy to a different >> source. If a domain has no MTA-STS policy, then a failure to reserve >> the mta-sts hostname might allow someone to register that subdomain, >> but that someone would still to MiTM the TXT record, and they could >> instead MiTM the MX records. >> >> So all that "mta-sts" buys them is the ability to create an extended >> DoS, until the domain owner takes over "mta-sts" and publishes a new >> TXT record. It's not great that the DoS could happen, but recovery >> is just taking back control of the delegation. >> >> That said, I share your concern about reserved hostnames. The only >> realistic alternative is to require "example.com" rather than >> "mta-sts.example.com", which limits HTTPS hosting options. >> >> MTA-STS is a kludge to avoid DNSSEC, and some contortions and caveats >> are inevitable. >> >> > Yup -- this has (and please correct me if I'm wrong) the properties that: > 1: people (systems) shouldn't resolve the mta-sts.example.com name > without the _mta-sts.example.com name telling them to. > 2: this is "restrictive" - if I happen to be able serve something from > mta-sts.example.com I cannot "gain" any privileges or access - all I can > do is cause a DoS. > > For #1, I get that the existence of the _mta-sts label *should* be the > signal that the mta-sts exists and means something... but you *know* some > programmers are lazy and will just attempt to fetch > https://mta-sts.example.com/.well-known/mta-sts.txt and see if it works. > > For #2: if I happen to already have a machine called mta-sts.example.com > (e.g: Metro Transport Agency - Security Theatre System) or can cause a > webserver to have that name (mta-sts.blogspot.com) I cannot redirect > mail, "all" I can do is DoS mail (coupled with #1). > > The fact that this is restrictive use case makes me less concerned, but > I'm scared about creating the pattern. > An example of when something similar to #2 caused issues (in a > non-restrictive case) are the cases where mail servers operators haven't > reserved e.g hostmaster@, someone has been able to get that as an email > address and then use that to get a DV cert, transfer the domain, etc. > Unless everyone knows that an identifier needs to be reserved, it can cause > entertainment... > > I'm still deeply uncomfortable with reserving a label by fiat, but I think > that much of my concerns can be alleviated by adding some more text to the > document explaining *why* this approach was taken. Ie: why "_ > mta-sts.example.com. TXT "v=STSv2; id=20180114T070707; label=foo" isn't > affective -- I understand your security argument, but I think explaining > this in the document would be useful to prevent / minimize the precedence > setting. > > I also think that someone, somewhere should write a document which creates > a registry for names like this -- AFAICT, this is the first time that we > would be doing something like this (for non-underscore names). > Dave Crocker has a draft with created an _underscore registry - > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ - this > document should probably be added to that. > > W > > >> -- >> Viktor. >> >> > > -- > I don't think the execution is relevant when it was obviously a bad idea > in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
