On Fri, Dec 12, 2014 at 12:55:50AM +0000, Viktor Dukhovni wrote: > On Fri, Dec 12, 2014 at 11:41:30AM +1100, Mark Andrews wrote: > > [stuff about indirecting via a keyserver elided]
SUBMIT/SMTP itself could act as the keyserver. There are two use cases: validate a sender's signing certificate, and get a recipient's encryption certificate. Both mean contacting the peer's domain's keyserver, but we could indirect through any SUBMIT server that the MUA can talk to, and we can authenticate any replies via DNSSEC in a way that does not permit walking the zone. I.e., Client: connect to C's MSA Client: VRFY_SENDER_CERT [email protected] cert-hash MSA: connect to sender.domain's MTA MSA: VRFY_SENDER_CERT [email protected] cert-hash The MTA responds, the MSA forwards the response. The client also does a DNS lookup for base32(H(sender certificate || sender address))._smimesendercert.sender.domain. and [hopefully] finds base32(H(sender address)). No need for the client to talk to sender.domain's MTA directly, so no concerns about port 25 blocking. And if the MSA lies, the client will find out. The client has to speak SUBMIT/SMTP anyways, and it has to support doing so with TLS (which the client's MSA surely will speak, and the network damned well ought to permit). > The downside of something other than HTTPS or DNS, is that while > less likely to be blocked for anti-spam reasons, this is likely to > be inaccessible to MUAs inside various firewalled environments. See above as to firewalls. But it's true that a pure DNSSEC scheme means that the client can encrypt e-mail to / validate e-mail signatures without having to worry about downgrade attacks on SMTP. We'd still want the client to use TLS for SUBMIT/SMTP though. A middle of the road might be that domains could publish RRSets for local-parts they don't mind people being able to walk, but not for those they do, with the trade-off being that the latter lose security (or access) when networks attempt MITM downgrade attacks on StartTLS. > Perhaps a sufficiently light-weight http encapsulation is right > after all, and MTA authors might be able to implement just enough > HTTPS to still support this as an MTA feature. Why HTTP? > [...] > This however takes far away from any similarity to the SMIMEA draft > as it is today. Is it really time to throw it all away and start > again? Maybe so. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
