On Fri, May 11, 2018 at 6:16 AM Daniel Margolis <[email protected]> wrote:
> I also want to point out (in regards to Warren's comment) that someone who > controls mta-sts.example.com *and can inject the _mta-sts TXT record* can > only redirect mail insofar as they could do so otherwise--because they will > still need to tamper with the MX records, and tampering with MX records > (absent DNSSEC, which prevents the whole thing) allows redirection of mail > *absent* STS. So in general we introduce no extra risk on mail > *redirection* so much as a risk of sustained DoS: my biggest fear with > the whole scheme was creating an opportunity for attackers to serve a > policy that bounces legitimate mail, and that less than savvy admins would > have trouble revoking that policy. However, since that requires a magical > TXT record (assuming no lazy implementations!), that attacker who can write > to the DNS zone can probably also inject an MX record with a long TTL--not > quite the same thing, but somewhat similar. (These concerns are discussed > similarly in Security Considerations.) > > I agree this is a convention and not a reservation, to Ted's point. > Ok. Would you be able to craft some text around that? W > > > On Fri, May 11, 2018 at 12:07 AM Viktor Dukhovni <[email protected]> > wrote: > >> >> > On May 10, 2018, at 5:39 PM, Ted Hardie <[email protected]> wrote: >> > >> > 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. >> >> What might help is that not many lazy programmers get to write MTA >> implementations, particularly with fancy bells and whistles like >> MTA-STS. They're more likely to write SUBMIT clients, which are >> not in scope for this specification. >> >> And thus, indeed "mta-sts.example.com" has no special meaning unless >> the TXT record is also present. >> >> So this feature of the spec is somewhat unfortunate, but perhaps >> the right tradeoff vs. limiting deployment to domains that are >> able to serve the policy from "https://example.com";. Folks >> operating organizational websites can speak more to how much >> of a burden such a constraint might be. >> >> -- >> 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 [email protected] https://www.ietf.org/mailman/listinfo/uta
