On Thu, Jul 27, 2017 at 9:05 AM, Vittorio Bertola < vittorio.bert...@open-xchange.com> wrote:
> > Il 26 luglio 2017 alle 19.10 Brandon Long <bl...@google.com> ha scritto: > > Why can't smtp software being expected to maintain a list of trusted CAs? > Or at least run on an OS that is expected to do so. > > There is a standard explanation (literally) in RFC 7672, section 1.3, and > especially 1.3.4.: > > "Even if it were generally possible to determine a secure server name, the > SMTP client would still need to verify that the server's certificate chain > is issued by a trusted CA (a trust anchor). MTAs are not interactive > applications where a human operator can make a decision (wisely or > otherwise) to selectively disable TLS security policy when certificate > chain verification fails. With no user to "click OK", the MTA's list of > public CA trust anchors would need to be comprehensive in order to avoid > bouncing mail addressed to sites that employ unknown CAs. > > On the other hand, each trusted CA can issue certificates for any domain. > If even one of the configured CAs is compromised or operated by an > adversary, it can subvert TLS security for all destinations. Any set of CAs > is simultaneously both overly inclusive and not inclusive enough." > Well, yes, that is the DANE argument in a nutshell. That doesn't mean it's correct, and there are reasons why DANE was not the solution chosen for the browser market. I think because of the historical weakness of SMTP, that we have to upgrade to security, that DANE may be the better solution in this case, but we shouldn't kid ourselves that the problems identified with it in the browser world don't apply also. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
