On Fri, 2012-08-10 at 15:20 -0700, Chris Palmer wrote: > * It's not clear that SMTP over TLS is very beneficial, because you > can't stop delivery due to pin validation failure (or really even > regular old X.509 failure).
That depends. Key pinning may not be very interesting for accepting coming mail from unknown sources, but it may be very interesting when TLS is used for communication between cooperating components of an enterprise mail system, or with an outsourced anti-smap or anti-virus or backup MX service. And of course, it's also interesting when TLS is used to protect authenticated mail submission services -- a user sending outgoing mail via his ISP probably doesn't want to tell his username and password to just anyone. > * SSH already has PKP. Well, no. Certainly, SSH clients making a leap-of-faith connection to a previously unknown host will generally remember that host's public key. And yes, once a host's public key is known, clients will generally reject a host that presents a public key other than the one known for that host. But then, web browsers do the same thing for leap-of-faith connections to web servers, when a server has a self-signed certificate or one signed by an unknown CA. But while this behavior is common, it is not required by any standard, not something I'd expect an SSH client to do when an X.509 certificate is used, and not the same thing as key pinning. So in fact, if this gets done at the application layer, it likely will eventually have to happen for SSH, too. I would really rather not see a proliferation of application-layer extensions to handle pinning of the long-term keys used for TLS. While I haven't participated in previous discussion on this question, I think that in the long run this is much better handled at the TLS layer. That said, there may be a benefit to solving the problem for HTTP at the HTTP layer, _if_ doing so allows us to get something deployed more quickly than a TLS-layer solution. -- Jeff _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
