Hiya, On 11/27/2013 06:58 PM, Nico Williams wrote: >>> I could imagine something like Received headers to document how each >>> SMTP (and SUBMIT) end-point was authenticated (if they were) along a >>> mail transfer path. This would be of some utility, particularly for >>> *short* paths (MUA->MSA->MTA->mailbox); for longer paths this loses its >>> utility. >> >> Not sure I get the utility there, at least as in scope for >> this proposed WG. Do you mean the receiving MUA would display >> the message differently or something? > > Yes. You get an e-mail from me. Your edge MTA authenticated my MTA and > my MTA claims to have authenticated me. Add in a signature by my MSA > over the relevant headers and body and your MUA can display my e-mail as > more authenticated than one that transited a non-secure link (or where > the transfer path was longer).
I'm not sure detecting the path length in terms of ADMDs is so easy, not so useful in terms of MTAs (with all the spam checking that can go on), nor that the above is really explicable to users. We'd need to ask some mail folks. But I like the emerging scheme below a good bit more:-) > Note that there'd be a need for using DANE to authenticate MTAs acting > as *clients*. There'd be no need to prove the use of DANE for > authenticating MTAs acting servers: if the mail gets to its intended > destination, and the transit path is the shortest possible path, then > we're good to go. But it'd still be desirable to use DANE for > authenticating MTAs acting servers: to prevent e-mail falling into the > wrong hands. > > Note too that if a path is longer than the absolute shortest possible > path then it's difficult to verify that there was no MITM in the path. > That is, an MTA along the path could have had its DNS MX RR lookups > spoofed so as to transfer my email to you via an MITM (who then gets to > see it). It's not like a client can prove to a server that the client > used DANE to authenticate the server, so the servers can't protect > against this. The shortest path will generally be: my MUA->my MSA, my > MTA -> your MTA, your MTA -> your mailbox. Internal MTA hops on my > and/or your side are irrelevant and can be noted as such or even not > recorded (assuming our respective internal networks are secure). Policy > could be used to validate longer-than-shortest paths, but in practice > just the shortest-path approach will suffice. > >> There might be an idea there though if some of the hops used >> e.g. anon-DH and someone developed a generic witness protocol >> to help try spot MITM attacks on that, and if the MSA and MTAs >> DKIM-sign messages, then a message header field containing the >> inbound & outbound witness-protocol PDUs that was included in >> the DKIM signature could be good. > > If there's just anon-DH it's not terribly useful except as a way to > bootstrap up to using DANE. If you use DANE then you get the above > property (all hops authenticated == much better than one [or more] hops > not authenticated). Not sure I agree with you there, esp if something could be bound to DKIM at or by the ADMD TLS endpoints. The problem with DANE is the lack of DNSSEC. If we had both I fully agree it'd be better than using anon-DH. But I figure there's a chance mail providers could do a DKIM thing in the very near future and get some benefit. Otherwise I think we're in agreement and I'll send a pointer to this sub-thread to apps-discuss so follow up can happen there. (I think you're on that list right?) Cheers, S. >> That sounds like it'd be a bit out the scope for UTA but if >> that's what you meant (or similar) but I'd say a mail to >> apps-discuss on that would be useful. > > Right. > >> But I don't think we'd want the UTA WG to be the one to >> develop a protocol for how to post-facto spot a MITM on anon-DH >> or other TLS sessions though. (Anyone got suggestions for that >> btw? Probably a different thread though.) > > Agreed. > >> (And yes, the above would depend on DKIM public key records in >> the non-DNSSEC DNS, so a DANE like thing and DNSSEC would be >> stronger, but given that lots of large and small mail services >> already do DKIM and don't change their keys that often, even >> the non-DNSSEC thing might be good enough.) > > I'd prefer the hop-by-hop DANE thing for e-mail. It makes much more > sense. > _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
