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? <csg>
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? d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
At 01:34 AM 11/14/2011, Dave CROCKER wrote: >what's the purpose? what problem is this intended to solve? how >prevalent is that problem now? There was a discussion about this subject a year ago ( it may be related to http://www.ietf.org/mail-archive/web/yam/current/msg00420.html ). I vaguely recall some discussion about SSL certificate verification. See RFC 6125 as well. Regards, -sm
At 01:34 AM 11/14/2011, Dave CROCKER wrote:what's the purpose? what problem is this intended to solve? how prevalent is that problem now?
There was a discussion about this subject a year ago ( it may be related to http://www.ietf.org/mail-archive/web/yam/current/msg00420.html ).
I vaguely recall some discussion about SSL certificate verification. See RFC 6125 as well.
% ls /srv/docs/internet/rfc6???.txtDoh.
ls: No match.
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>
On 11/15/2011 4:10 AM, 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. Isn't that exactly the problem that the DANE working group attacking. If not, how is it different? Can this issue be extended from their work? d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
Dave CROCKER wrote: > On 11/15/2011 4:10 AM, Carl S. Gutekunst wrote: >> 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. > > Isn't that exactly the problem that the DANE working group attacking. DANE is looking at DNSSEC extensions, which may well be what Tony was looking for. However, one of the references for DANE -- RFC 6125 -- seems to be exactly what I was looking for. Unfortunately, it very deliberately codifies the language from RFC 2818 for wildcards, with the established practice for SMTP being a SHOULD NOT. I'll have to figure out what to do about that. (That said, I can count the number of MTA implementations that support wildcard domains in certificates without taking off my shoes.) Thanks! <csg>
On 14/11/2011 22:40, Carl S. Gutekunst wrote: > Dave CROCKER wrote: >> On 11/15/2011 4:10 AM, Carl S. Gutekunst wrote: >>> 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. >> >> Isn't that exactly the problem that the DANE working group attacking. > > DANE is looking at DNSSEC extensions, which may well be what Tony was > looking for. > > However, one of the references for DANE -- RFC 6125 -- seems to be > exactly what I was looking for. Unfortunately, it very deliberately > codifies the language from RFC 2818 for wildcards, with the > established practice for SMTP being a SHOULD NOT. Backward compatibility might be a sufficient reason to violate the SHOULD NOT. > I'll have to figure out what to do about that. (That said, I can count > the number of MTA implementations that support wildcard domains in > certificates without taking off my shoes.) > > Thanks! > > <csg>
Alexey Melnikov wrote:
>> ... one of the references for DANE -- RFC 6125 -- seems to be exactly
>> what I was looking for. Unfortunately, it very deliberately codifies
>> the language from RFC 2818 for wildcards, with the established
>> practice for SMTP being a SHOULD NOT.
> Backward compatibility might be a sufficient reason to violate the
> SHOULD NOT.
I don't think it's that easy. The issue is with Email virtual hosting
implementations that embed the virtual domain name (or any token with
dots in it) in the MX record. For example, if you look up the MX record
for gutekunst.org, you'll see:
gutekunst.org. 86382 IN MX 100
gutekunst.org.s8a1.psmtp.com.
gutekunst.org. 86382 IN MX 200
gutekunst.org.s8a2.psmtp.com.
gutekunst.org. 86382 IN MX 300
gutekunst.org.s8b1.psmtp.com.
gutekunst.org. 86382 IN MX 400
gutekunst.org.s8b2.psmtp.com.
Postini's SSL certificate reads:
Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.psmtp.com
I'm sure they aren't the only ESP that does this; MXLogic for sure,
probably CheckFree, possibly FrontBridge.
<csg>
Carl S. Gutekunst wrote:
>
> Alexey Melnikov wrote:
>> Backward compatibility might be a sufficient reason to violate the
>> SHOULD NOT.
>
> I don't think it's that easy. The issue is with Email virtual hosting
> implementations that embed the virtual domain name (or any token with
> dots in it) in the MX record. For example, if you look up the MX record
> for gutekunst.org, you'll see:
>
> gutekunst.org. 86382 IN MX 100
> gutekunst.org.s8a1.psmtp.com.
> gutekunst.org. 86382 IN MX 200
> gutekunst.org.s8a2.psmtp.com.
> gutekunst.org. 86382 IN MX 300
> gutekunst.org.s8b1.psmtp.com.
> gutekunst.org. 86382 IN MX 400
> gutekunst.org.s8b2.psmtp.com.
>
> Postini's SSL certificate reads:
>
> Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.psmtp.com
>
> I'm sure they aren't the only ESP that does this; MXLogic for sure,
> probably CheckFree, possibly FrontBridge.
Very interesting. I can see this will need to be addressed in our
server where, if enabled, the certificate is stored based on the CN
name. Using our consoled-based SMTP testing client, here is the result:
* connecting to host: gutekunst.org.s8a1.psmtp.com ip: 64.18.7.10:25
S: 220 Postini ESMTP 296 y6_45_0c2 ready. CA Business and Professions
Code Section 17538.45 forbids use of th
is system for unsolicited electronic mail advertisements.
C: EHLO main2.addom.santronics.com
S: 250-Postini says hello back
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 HELP
C: STARTTLS
S: 220 Go ahead
** SSL Negotiated session
!! ERROR 123 - saving server's cert to *.psmtp.com.cert
** CERT Common Name : *.psmtp.com
** CERT Organization: Google Inc
** CERT Valid Until : May 25 00:34:28 2012 GMT (Days Left: 191)
** CA Country : US
** CA Organiziation : Google Inc
** CA Common Name : Google Internet Authority
!! connection domain : gutekunst.org.s8a1.psmtp.com
!! common name : *.psmtp.com
!! Certificate CONNECTION DOMAIN and COMMON NAME mismatch! Accept? Yes
or No?
The error is minor, of course, but I can see your point here. I did
another run with a match check of the computer name (rDNS) and got this:
!! computer name : s8a1.psmtp.com
!! common name : *.psmtp.com
!! Certificate COMPUTER NAME and COMMON NAME mismatch. Accept? Yes or No?
I wonder how the current MUAs will work here. What have you see with
the MUAs? like OE, Thunderbird and others?
To answer your question about interest, here is what I think:
First, I think getting a baseline of who are the beneficiaries, is the
client mandating correctness or if the server requiring a correct
matching client certificate?
Second, finding out if wild cards is done in this fashion across the
board. Is this how its done all CA do it? I think OCSP should be
looked at as a possible optional solution or something that would be
part of the validation suite:
RFC2560 X.509 IPKI Online Certificate Status Protocol, Updated by
6277
RFC6277 Online Certificate Status Protocol Algorithm Agility
RFC4806 Online Certificate Status Protocol (OCSP) Extensions to IKEv2
My experience here began with a very large national chain customer who
paid the bucks for a wild card certificate and unbeknownst to them,
there was some SSL purchasing mixup issue that the CA revoked had
revoked it. But that didn't show up with the browsers (no SSL error)
until some users with updated browsers which now had OCSP enabled
began to show the insecure warning error "do you wish to continue"
pages. That provided the clue that there was an SSL purchasing mix up
with the group of domains they wanted signed by the CA. Turning off
the OSCP at the browser got by it, but of course, thats not realistic
to presume to be off with new browsers now enabling it.
and third, work out the "algorithm" for the matching options of the
CN, possibly by first seeing the current practice by MUAs where there
is an interactive HUMAN involved to help with the decisions. The end
goal here is to see is automation is possible with two MTAs.
Keep in mind, at least for us where we have it setup on a per remote
host setup where specific MTA connection details are provided for a
target email domain or host, they could bypass the MX host. For
example, I did the same test run for your domain:
* connecting to host: mail.gutekunst.org.s8a1.psmtp.com ip:
128.177.28.115:25
S: 220 alameth.user.openhosting.com ESMTP Postfix (2.4.1)
C: EHLO main2.addom.santronics.com
S: 250-alameth.user.openhosting.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250 DSN
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
** SSL Negotiated session
** CERT Common Name : mail.gutekunst.org
** CERT Organization:
** CERT Valid Until : Nov 10 22:35:42 2012 GMT (Days Left: 361)
** CA Country : IL
** CA Organiziation : StartCom Ltd.
** CA Common Name : StartCom Class 1 Primary Intermediate Server CA
!! computer name : 128-177-28-115.ip.openhosting.com
!! common name : mail.gutekunst.org
!! Certificate COMPUTER NAME and COMMON NAME mismatch. Accept? Yes or
No? n
So it passed the connection name test, and it would pass the computer
name test if I disable the rDNS matching check.
Point here is I believe that when it comes to prearranged remote host
routing, the authentication and TLS details may be already worked out
for validation.
--
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector <at> jabber.isdg.net
At 18:14 -0800 on 11/14/2011, Carl S. Gutekunst wrote about Re: Any interest in rigorous definition for SSL certificate: >Alexey Melnikov wrote: > >> ... one of the references for DANE -- RFC 6125 -- seems to be exactly >>> what I was looking for. Unfortunately, it very deliberately codifies >>> the language from RFC 2818 for wildcards, with the established >>> practice for SMTP being a SHOULD NOT. >> Backward compatibility might be a sufficient reason to violate the >> SHOULD NOT. > >I don't think it's that easy. The issue is with Email virtual hosting >implementations that embed the virtual domain name (or any token with >dots in it) in the MX record. For example, if you look up the MX record >for gutekunst.org, you'll see: > > gutekunst.org. 86382 IN MX 100 > gutekunst.org.s8a1.psmtp.com. > gutekunst.org. 86382 IN MX 200 > gutekunst.org.s8a2.psmtp.com. > [snip] > >Postini's SSL certificate reads: > > Subject: C=US, ST=California, L=Mountain View, O=Google Inc, >CN=*.psmtp.com Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is needed to map the s8XX section) to solve this issue? - or is more than one wild card level invalid or having more than one certificate with different specificity levels also invalid?
Robert A. Rosenberg wrote: > Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is > needed to map the s8XX section) to solve this issue? - or is more than > one wild card level invalid or having more than one certificate with > different specificity levels also invalid? First thing I thought of.Alas, RFC 6125 explicitly disallows multiple wildcard characters. I want to read through the archives for the WG that published RFC 6125 so I understand their reasoning better; although they reference RFC 4954, I'm still wondering if the WG had any input from anyone in the SMTP space. As Tony noted, matching at a single level is incompatible with DNS's own wildcard semantics. And the document's writing style and voice feels much more like a BCP, not a standards track protocol specification. <csg>
On 16/11/2011 03:04, Carl S. Gutekunst wrote: > Robert A. Rosenberg wrote: >> Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is >> needed to map the s8XX section) to solve this issue? - or is more >> than one wild card level invalid or having more than one certificate >> with different specificity levels also invalid? > > First thing I thought of.
On 16/11/2011 02:44, Robert A. Rosenberg wrote: > > At 18:14 -0800 on 11/14/2011, Carl S. Gutekunst wrote about Re: Any > interest in rigorous definition for SSL certificate: > >> Alexey Melnikov wrote: >> >> ... one of the references for DANE -- RFC 6125 -- seems to be exactly >>>> what I was looking for. Unfortunately, it very deliberately codifies >>>> the language from RFC 2818 for wildcards, with the established >>>> practice for SMTP being a SHOULD NOT. >>> Backward compatibility might be a sufficient reason to violate the >>> SHOULD NOT. >> I don't think it's that easy. The issue is with Email virtual hosting >> implementations that embed the virtual domain name (or any token with >> dots in it) in the MX record. For example, if you look up the MX record >> for gutekunst.org, you'll see: >> >> gutekunst.org. 86382 IN MX 100 >> gutekunst.org.s8a1.psmtp.com. >> gutekunst.org. 86382 IN MX 200 >> gutekunst.org.s8a2.psmtp.com. >> [snip] >> >> Postini's SSL certificate reads: >> >> Subject: C=US, ST=California, L=Mountain View, O=Google Inc, >> CN=*.psmtp.com I would like to know how well this kind of SubjectName DN works for email clients. Do you have any information on this? > Why not use a Certificate with CN=*.*.s8??.psmtp.com (or whatever is > needed to map the s8XX section) to solve this issue? - or is more than > one wild card level invalid or having more than one certificate with > different specificity levels also invalid? I don't think "?" is allowed. Multiple wildcards are either disallowed or discouraged by RFC 5280.
Carl S. Gutekunst <csg <at> alameth.org> wrote: > > However, one of the references for DANE -- RFC 6125 -- seems to be exactly > what I was looking for. Unfortunately, it very deliberately codifies the > language from RFC 2818 for wildcards, with the established practice for SMTP > being a SHOULD NOT. I'll have to figure out what to do about that. That is bizarrely incompatible with DNS wildcard semantics. Tony. -- -- f.anthony.n.finch <dot <at> dotat.at> http://dotat.at/ Plymouth: Easterly 5 or 6, occasionally 7 in north, veering southeasterly 4 or 5 later. Moderate, occasionally slight later. Mainly fair. Moderate or good.
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>
Carl S. Gutekunst <csg <at> alameth.org> 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? I am interested. STARTTLS as it is currently used is fine for message submission, but it could do with a more precise specification. For inter-domain SMTP, STARTTLS is hopeless because the majority of MX server certificates cannot be verified, as Carl has previously described on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html So we need something that allows MXs to say explicitly, "please strictly verify my certificate". For this to be any use it needs downgrade prevention, which probably requires a declaration in the DNS protected with DNSSEC. There is also the problem of which identity is to be verified. There is no point verifying the MX target host name unless the recipient's DNS zone is signed and the sender's MTAs are doing DNSSEC validation. If you prefer to avoid requiring DNSSEC, you must verify the recipient mail domain. In this case you have a much greater need for some kind of support for server certificate selection (either SNI in TLS or perhaps a new ESMTP TLS service extension), and you have to decide how to deal with messages that have recipients at multiple different domains on the same MX target server. This is all rather complicated and messy. Tony. -- -- f.anthony.n.finch <dot <at> dotat.at> http://dotat.at/ Lundy, Fastnet, Irish Sea: East or southeast 5 to 7, decreasing 4 at times. Moderate or rough, occasionally very rough in Fastnet. Fair. Moderate or good, occasionally poor later.
In message <alpine.LSU.2.00.1111141302170.30178 <at> hermes-2.csi.cam.ac.uk>, Tony Finch writes: > > Carl S. Gutekunst <csg <at> alameth.org> 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? > > I am interested. > > STARTTLS as it is currently used is fine for message submission, but it > could do with a more precise specification. > > For inter-domain SMTP, STARTTLS is hopeless because the majority of MX > server certificates cannot be verified, as Carl has previously described > on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html > > So we need something that allows MXs to say explicitly, "please strictly > verify my certificate". For this to be any use it needs downgrade > prevention, which probably requires a declaration in the DNS protected > with DNSSEC. > > There is also the problem of which identity is to be verified. There is no > point verifying the MX target host name unless the recipient's DNS zone is > signed and the sender's MTAs are doing DNSSEC validation. > > If you prefer to avoid requiring DNSSEC, you must verify the recipient > mail domain. In this case you have a much greater need for some kind of > support for server certificate selection (either SNI in TLS or perhaps a > new ESMTP TLS service extension), and you have to decide how to deal with > messages that have recipients at multiple different domains on the same MX > target server. This is all rather complicated and messy. We have RFC's which say that the target of the MX record should be the canonical name of the server. We have RFC's which allow us to validate as secure MX records (implicit and explict). DANE is looking at signalling that secure services for a port exist. We have everything in these RFCs / drafts to do STARTTLS in general rather than just submission and avoid downgrade attacks. With MX example.net MX 0 mail.example.net _25._tcp.mail.example.net TLSA mail.example.net A mail.example.net AAAA Wildcard MX *.example.net MX 0 mail.example.net _25._tcp.mail.example.net TLSA mail.example.net A mail.example.net AAAA Without MX example.net A example.net AAAA _25._tcp.example.net TLSA (Implict MX "example.net MX 0 example.net") Without MX and with CNAME example.net CNAME example.com example.com A example.com AAAA _25._tcp.example.com TLSA (Implict MX "example.net MX 0 example.com") All the zones involved above are DNSSEC signed with secure delegations. > Tony. > -- > f.anthony.n.finch <dot <at> dotat.at> http://dotat.at/ > Lundy, Fastnet, Irish Sea: East or southeast 5 to 7, decreasing 4 at times. > Moderate or rough, occasionally very rough in Fastnet. Fair. Moderate or good, > occasionally poor later. > -- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka <at> isc.org
Tony Finch wrote: > STARTTLS as it is currently used is fine for message submission, but it > could do with a more precise specification. > > For inter-domain SMTP, STARTTLS is hopeless because the majority of MX > server certificates cannot be verified, as Carl has previously described > on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html > I think the situation has improved slightly. All of the Fortune 500 domains I'd identified in 2008 as having unverifiable certificates have since been fixed. I'm also seeing more customer interest in more robust TLS deployments, particular from the Federal Government. > So we need something that allows MXs to say explicitly, "please strictly > verify my certificate". For this to be any use it needs downgrade > prevention, which probably requires a declaration in the DNS protected > with DNSSEC. > > There is also the problem of which identity is to be verified. There is no > point verifying the MX target host name unless the recipient's DNS zone is > signed and the sender's MTAs are doing DNSSEC validation. > I think that latter element as it the heart of the DANE working group? (No, I hadn't heard of that WG until Dave pointed it out.) > If you prefer to avoid requiring DNSSEC, you must verify the recipient > mail domain. In this case you have a much greater need for some kind of > support for server certificate selection (either SNI in TLS or perhaps a > new ESMTP TLS service extension), and you have to decide how to deal with > messages that have recipients at multiple different domains on the same MX > target server. This is all rather complicated and messy. I'm trying to stay simple at this point, and only verify the recipient MX server, not the recipient domains. That's already being widely done, but (as I noted to Dave) without any clear specification for how to do that in SMTP. However, as I go through RFC 6125, it pretty much does seem to be covering everything I wanted (other than deprecating the current common practice... *SIGH*) <csg>
Carl S. Gutekunst <csg <at> alameth.org> wrote: > Tony Finch wrote: > > > > For inter-domain SMTP, STARTTLS is hopeless because the majority of MX > > server certificates cannot be verified, as Carl has previously described > > on this list http://www.imc.org/ietf-smtp/mail-archive/msg05366.html > > I think the situation has improved slightly. Good
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? Our SMTP client has options to check the server certificate on a per domain basis. So where it is mandated that it be non-expired and common names match the connection name and/or the rDNS is local policy. But one thing I was thinking about supporting is OCSP (Online Certificate Status Protocol) RFC2560 as the another way to check for the vendor revocation and also deal with the wild card issues. The major browsers do OCSP and at first it was OFF by default. But within the last year or so of updates, they are now ON by default, specifically starting with CHROME and FIREFOX 3.0. I think this may be doable today if the SMTP client wanted to push the check that far. -- -- Sincerely Hector Santos http://www.santronics.com jabber: hector <at> jabber.isdg.net
RSS Feed