Hiya, On 16/04/15 19:45, Viktor Dukhovni wrote: > On Thu, Apr 16, 2015 at 07:28:58PM +0100, Stephen Farrell wrote: > >>> 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). > > Note that for this protocol, both the address records and the TLSA > records of the MX host are DNSSEC-validated, since when the address > records are not, we don't even ask for the TLSA RRs. So I am not > sure what you have in mind...
Yep - this could be me being confused. If there's no way in which the MX and TLSA can be properly signed but where the A is not, then I agree my comment is moot and no change is needed. Cheers, S. PS: The rest below is fine. > > When the MX host's DNS zone is signed, both the address and the > TLSA records are signed, and off-path attackers don't get to use > DNS to redirect the traffic to addresses that are on-path. They > are of course still free to attempt to mess with the routing layer > to whatever extent possible. > >>>> - 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. > > Some SMTP servers send certificate requests anyway, most don't. > Sending MTAs, most of which are not configured with client certs, > just ignore the requests. Receiving MTAs complete the handshake > even if no client certificats are sent, but don't grant whatever > additional access rights one may get with some particular client > cert (or simply can't, when absent, record any client cert details > in "Received" headers or mail logs). > > So there's nothing really to say here, we're not changing the status > quo in any way (yet). Once there's a protocol for client TLSA RRs, > then there'll be something to say. > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
