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 "*.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>