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...
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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
