Hiya, On 16/04/15 18:37, Viktor Dukhovni wrote: > 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.
My understanding is that some people wanted to experiment with TLSA without having to have had DNSSEC deployed. But I take your answer to be that no such behaviour is defined here, which is fine. So consider this one answered. > >> (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. I see Paul has replied so I'll see how the discussion develops and join in later. A few bits more below on the non-blocking things. > > 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. So I think the threat is that someone who fakes the A record can do traffic analysis as they can direct the SMTP and STARTTLS traffic through their chosen host. I think that's work noting, in and of itself. If we had more to say (that's well founded) about traffic analysis if SMTP/TLS that'd be interesting but I'm not familiar with any work in the space (though I've not looked). > >> - 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". I'm fine if you just take a peek again and decide what to do. > >> - 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. I think that's needed, or perhaps a reference. In my reading I never even considered DS RR's. Now that might be my relative ignorance of DNSSEC terminology, but that's a new one on me so please either define it if it's a neologism or else just add a reference if it's a know term of art. > >> - 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. Could be worth saying that mutually authenticated TLS is out of scope so servers SHOULD (or MUST) NOT send a certificate request. > >> - 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. ] Ok, it's that latter I was after. If someone maintains that those specific server deployments are significant they can make that case during last call I guess. Ta. > >> - 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. I'll chime in later. > >> - 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). Ditto. > >> - 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). Sorry, I meant that lots of 9.2 repeats things said earlier in this document. Cheers, S. > _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane