Dave CROCKER wrote:
On 11/14/2011 3:57 PM, Carl S. Gutekunst wrote:
RFC 3207 punts on the issue of certificate verification. Is there any
interest
in a rigorous specification for certificate verification in
SMTP/STARTTLS ? Is
this the appropriate WG for such a discussion?
what's the purpose? what problem is this intended to solve? how
prevalent is that problem now?
The purpose is to define a standard way for an SMTP sender (client) to
determine that the SMTP receiver that it's talking to is the one it
thinks it's talking to. The mechanism would detect man-in-the-middle
attacks and connection hijacking at either the routing or DNS level.
I agree completely with the language in RFC 3207 that says "The decision
of whether or not to believe the authenticity of the other party in a
TLS negotiation is a local matter." It has to be that way, if only
because of the highly inconsistent deployment of PKI. But I think there
should be language that says SMTP senders MAY use TLS certificate
verification, and if they do, they MUST do it in the specified way.
There's obviously common practice; many of the MTAs that support TLS
also support some form of server certificate verification. However, the
behavior is all inferred from the TLS specifications for other
protocols, e.g., RFC 2818 section 3.1 for HTTP, or RFC 3501 section 11.1
for IMAP. As far as I know, the closest to an SMTP TLS spec is RFC 4954
Section 14, but that's only for SMTP AUTH. And I think the (almost
identical) language in RFC 2595, 3501, and 4954 is ambiguous and incomplete.
What got me (re)started on this was an argument over interpretation of
wildcard names. RFC 2818 (for HTTP) is clear that a wildcard matches the
current level only; but it is common practice among Email service
providers to match everything to the left. That is, given a dnsName in
the certificate of "*.a.com," it's clear in RFC 2818 that
"bar.foo.a.com" would not match. But the existing Email deployments
assume that it does, and I've heard folks argue that is what is implied
in RFC 2595.
<csg>