On 2012-06-11 22:57, Tony Finch wrote: > The point of client authentication is ... what?
It would make automatic or manual recognition of fraudulent e-mails much more simple and effective. These days I receive perhaps 100 e-mails a year from someone who claims to be from my bank and asks me to perform some important action. Currently I can not perform that action unless I do a careful risk assessment based on "received" headers and whatever, but I still can not be absolutely sure because it is all guesswork as no verified certificates are involved. Therefore I have to assume that all of those e-mails are fraudulent and as a result I miss the one important e-mail a year which was really from my bank. I should have done something to renew my credit card for example. With the feature that I am suggesting my mail system could tell me that "we have positively authenticated that this e-mail was sent to us by a server which is named mailserver.$my_bank.com". I could be quite confident that the e-mail actually arrived from my bank. Equally confident as when https connection to www.$my_bank.com presents a server certificate identified by _443._tcp.www.$my_bank.com TLSA record. My receiving MTA could make the authentication results available to my MUA either using the "Authentication-Results" header or by some other underlying mechanism. Obviously this overlaps with some other technologies. My bank could sign their e-mails using PGP or S/MIME, but in reality almost nobody except geeks does that because of various difficulties (the DANE + S/MIME work might finally make S/MIME signatures automatically verifiable). The bank's mail server administrators might be geeky enough to implement DAN(C)E on their servers. They would only need to set it up once and as a result all their outgoing e-mail could be positively identified coming from whoever controls their domain. DANE + S/MIME and DANE/DANCE + SMTP would be complementing each other, working on different levels of the e-mail infrastructure. Google apparently sees some benefit in presenting a verifiable client certificate in their outgoing SMTP sessions. -- Janne Snabb / EPIPE Communications [email protected] - http://epipe.com/ _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
