On 3/25/16 3:19 PM, Viktor Dukhovni wrote: > On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote: > >>> If the entire goal is to ensure the integrity of the RFC 6125 >>> "reference identifier" used to authenticate the nexthop SMTP >>> server, then it is perhaps a good idea to say so explicitly. >> The primary purpose was indeed to ensure the integrity of the reference >> identifier; this is discussed in the Security Considerations (section >> 6.2, paragraph 3). > If so, with DNSSEC validation required, CNAMEs need only be secured > to the extent that they affect "reference identifier" selection. > > * CNAME/DNAMEs between the MX qname and the owner domain of > the ultimate MX RRset definitely need to be validated. > > * For domains with no MX RRset, the absence of the MX RRset > would potentially need to be DNSSEC validated. > > * Otherwise, CNAMEs only need to be validated to the extent > that (e.g. following RFC 7672) the ultimate "reference > identifier" is determined in whole or in part based on > the result of the CNAME lookup.
Sounds right to me. Thanks for spelling it out. I'll get it into the next revision. > >>> <quote> >>> The CHAIN and DANE parameters are additive; if both are specified, >>> either method of certificate validation is acceptable. If neither >>> CHAIN nor DANE is specified, the certificate presented by the SMTP >>> server is not required to be verified. >>> </quote> >>> >>> This is reasonably clear, either suffices when both are specified. >>> I am concerned that giving the user the choice to specify either >>> alone, rather than just a single "AUTHENTICATED" (or similar) >>> keyword, may be too much rope. >> By not using the CHAIN and DANE options, certificate verification is not >> required, so if too many messages are being bounced with those options, >> they'll not see use. But without those options, we're limiting the >> effectiveness of REQUIRETLS to passive attacks only; MITM attacks will >> still be possible. > NOTE: I am not suggesting that REQUIRETLS should not be able to > require authenticated TLS. Rather, I am (strongly) suggesting that > such a requirement needs be mechanism-neutral, and should not be > so specific as to be able to specify the use of DANE, WebPKI or > some future alternative. > >> I have received suggestions that there also be options to require >> specific TLS version, cipher suites, PFS, etc. as well, and my gut feel >> is that's getting too specific. > Don't let this be over-engineered. That's a guaranteed way to fail > to produce a workable protocol. Of course it is clear that even > a simple REQUIRETLS can gain sufficient traction, but to the extent > that you want this to have a fighting chance you should resist all > calls for overly-specific policy. I'm sensitive to over-engineering this. That said, there are mail senders who might consider their threat model to include an actor that has control over a commonly-accepted root certificate (as some nation-states do). Much of the motivation behind the CHAIN and DANE options was to allow such senders to be more specific about what forms of certificate verification they consider acceptable. This is probably a narrow use case, but perhaps very important for these senders. Let's see what the rough consensus is. -Jim _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
