On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote: > (1) What is the behaviour when all RRs required for this are > published except for no DNSSEC RRs? I have heard tell of some > people who would like to experiment in that way, and would > like to know if the WG have a clear answer for them as to > what ought happen. Is that answer here? (If so, it's fairly > well hidden;-)
The specified and implemented (Postfix and Exim) behaviour is that the records are ignored when not "secure". Thus DNSSEC is a prerequisite. Opportunistic TLS happens anyway (even without TLSA record validation), so it is not clear why one would bother with incomplete (easily defeated) attempts at protecting against active attacks. > (2) Doesn't this need to be consistent with other recent IETF > documents, in particular the generic UTA BCP and deprecating > SSL 3.0? I don't believe it current is entirely consistent > with either. (See minor comments below for details.) Why is > that ok? This is an opportunistic protocol, hence some security is better than none. If all that the server has is SSL 3.0, it can still publish TLSA RRs, and POODLE et. al, are primary attacks on HTTPS not SMTP. In any case this draft was ready (and has been largely unchanged) for about a year now, *before* all the fuss about SSL 3.0. Clients MUST support at least TLS 1.0 (to use SNI). Servers MAY support SSL 3.0 (allowing them to publish TLSA RRs with whatever they're running today). At this point we can set the floor at TLS 1.0 if that's better "optics", the number of servers doing just SSL 3.0, whose admins might be tempted to publish DANE TLSA RRs is likely zero. There is no reason to require anything beyond SSL 3.0 (server-side) in this protocol, and it does not preclude other documents from setting a higher bar. > The rest (below) are more minor comments, please treat these > as IETF LC comments. > Responding to a subset, leaving out mostly editorial fixes. > - 1.3.2, The MX lookup is vulnerable as stated but isn't the > A/AAAA similarly vulnerable? I think you ought note that too, > but also that this specification can mean that DNSSEC for > that lookup is not needed based on the name in the MX > response being bound (via x.509 or tlsa) to the TLS server > private key. (Well, that assumes I've gotten that correct:-) > Without DNSSEC for the MX name->address mapping a bad actor > could however, insert themselves into the path and gain > whatever can be gained via traffic analysis of the SMTP/TLS > session. The address records are not security relevant. MX is because authenticating the origin domain does not work, and the MX, absent DNSSEC, is insecure (but widely done anyway). While, the A records don't a-priori need to be secured, we skip TLSA records for MX hosts whose A/AAAA records are "insecure" in order to avoid interop problems with (Microsoft's and similar) domains whose non-DNSSEC nameservers are allergic to unsupported RRtypes (the "mail.protection.outlook.com" nameservers botch TLSA queries). Traffic hijacking can be done with BGP (this is far more common, and is more difficult to observe) even without changing the addresses. Or by tapping into the cables. > - 2.1.1, the term anchorless should probably get a mention in > 1.1 with a forward pointer to 2.1.1. Or maybe you can avoid > the term since it's not used much. (Just in 2 adjacent > paragraphs.) Yeah, that's a bit tricky, just need some way to avoid local repetition and to make it clear when we're describing the "4034" type of "indeterminate" once the definition of the term is aligned with "4035". Specific suggestions welcome, if this is important to "fix". > - 2.1.1, what does "securely opted out" mean? That's about a parent domain providing proof of non-existence of DS records, possibly with NSEC or NSEC3 for the domain itself, or perhaps via NSEC3 for neighbour domains with the opt-out bit set. Thus the domain is an "insecure" sub-domain of a "secure" parent domain. I'm open to better language if the current is confusing. > - 2.2, Could "authenticated" here mean mutually authenticated > with TLS client certs? If not, maybe say so. (And for the > last sentence before 2.2.1, what about the client cert names > - what's done with those?) There is no protocol for specifying mutual authentication until someone (I volunteered) writes the DANE draft for locating client TLSA RRs and how that works for SMTP. Some of the signaling (client -> server: please check for my TLSA records) will be application protocol specific. > - 3.1.2 - does the MUST include TA in the TLS handshake > conflict with common implementations of 5246? 5246 section > 7.4.2, says that the TA MAY be omitted, but I wonder if we > might be causing ourselves trouble (some) with running code. No, this is not a conflict. 5246 allows a shorter chain, but does not require it. With DANE the "optimization" is not available. Since verification without the TA cert is impossible, there is no choice. The requirement is a statement of logical fact, not a design choice. Running code is working just fine. The only real consequence is that some Microsoft (surprise?) Exchange servers reportedly can't actually add self-signed certs to their chain, so if they use a DANE-TA(2) trust anchor, it needs to be an intermediate. [ Either the admin tooling, Schannel, or something else in the stack does not make it possible to specify a server chain that includes a root CA. ] > - 8.1, para 1: We've (the IETF) just deprecated SSL 3.0, [1] > so don't you need to reference that and say to not do that? > At least the MAY at the end of that paragraph seems not to > conform with the BCP. I think a ref to [1] is needed. > > [1] https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie See above. The BCP does not claim applicability to opportunistic TLS. This protocol is (still) opportunistic TLS, but with authentication not just unauthenticated encryption. However, at this point SSL 3.0 has largely been phased out, so raising the bar to TLS 1.0 would have little practical effect. Server operators will ignore whatever we say here anyway and will support whatever they support. So whatever you want for "optics" is fine, though I still don't like erecting needless hurdles as a matter of principle. > - 8.2: This is already handled by the generic UTA BCP. Why is > it needed here? I don't see any discussion of anon-DH in the UTA BCP (which in any case disclaims applicability to opportunistic TLS). > - 9.2, 2nd para: isn't that repetitive? That seems like a bad > idea. Are we looking at the same draft version? Perhaps your 8.2/9.2 is not what I'm looking at (version 15). -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
