[Top] [All Lists]

Re: Any interest in rigorous definition for SSL certificate verification in SMTP?

2011-11-14 19:42:30

On 14/11/2011 20:10, Carl S. Gutekunst wrote:
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.
I agree that RFC 3207 is underspecified or outdated (depending on how one looks at this) in this area. I already have a draft (based on RFC 6125) that tries to address this problem to some extend: draft-melnikov-email-tls-certs-00.txt.

If you would like to help out with the above, please contact me off-list.
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.
Right. This is pretty much what motivated creation of RFC 6125.
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 "*," it's clear in RFC 2818 that "" 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.


<Prev in Thread] Current Thread [Next in Thread>