[cabfpub] Domain validation

[Tim Hollebeek]

I'll note that if you object to #6 on those grounds, you also object to #10, which is basically "do #6 via TLS, with fewer requirements around where the value must be placed."

In fact I'm starting to think that #10 should be eliminated and rolled into #6, simply by noting in #6 that for the purposes of #6, TLS with an untrusted server certificate can be used in place of HTTP.

-Tim

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Anoosh Saboori
Sent: Wednesday, May 06, 2015 7:46 PM
To: Ryan Sleevi
Cc: public at cabforum.org
Subject: Re: [cabfpub] Domain validation

Hi Ryan,

What you stated below partly is the main reason for us not supporting #6 . Another example is Azure tenant who is assigned "example.clouapp.net". While the tenant can pass the test in #6  by inserting nonce in "example.cloudapp.net/.well-known/certificate", they are not the real owner for that domain name, Azure is.

I also agree with your statement in regards to IP addresses.

Anoosh


________________________________
From: Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>
Sent: Wednesday, May 6, 2015 3:49 PM
To: Anoosh Saboori
Cc: Eddy Nigg; public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] Domain validation



On Wed, May 6, 2015 at 3:37 PM, Anoosh Saboori <ansaboor at microsoft.com<mailto:ansaboor at microsoft.com>> wrote:
Reviving this older thread. It seems that both:


1.       Forum has concerns around relying only on whois database or email address since the whois database might not be accurate

2.       MS still has concerns for #6 not being at par with the rest of validation mechanism proposed

So, can we get to a point where both concerns are addressed by modifying the requirement as: "#6 continues to be accepted, only if other validation methods failed to work. CAs then keep documentation on why they decided to accept #6. "


I'm still not sure why Microsoft doesn't feel that #6 is not on-par with the rest. It would be very helpful if you could elaborate what properties you feel that the other methods offer that #6 does not. In digging through your past replies, it only seems that you've highlighted it's "not as strong" - but you haven't clarified what property is absent.

If I understand by reading between the lines, your concern is that method #6 allows verification to happen by any attacker who can gain filesystem-level access, whereas the other methods require some level of password compromise (e.g. email, methods 1/2/4 from the original message), remote code execution (e.g. TLS bindings, method 11 from the original message), or has compromised the domain management (methods 7/8 from the original message). Is that correct?

I'm surprised that Microsoft hasn't highlighted Item 9 (IP address validation) as similarly weaker in guarantees. For example, in a shared hosting service, foo.com<http://scanmail.trustwave.com/?c=4062&d=-afK1aJC190ZIBtTTWDRZJ2ezKF8D9uNVuJuGOy9jA&s=5&u=http%3a%2f%2ffoo%2ecom> and bar.com<http://scanmail.trustwave.com/?c=4062&d=-afK1aJC190ZIBtTTWDRZJ2ezKF8D9uNVrI5HuDs3Q&s=5&u=http%3a%2f%2fbar%2ecom> may both be hosted on the same IP, and use SNI (for HTTPS) and the Host: header (for HTTP) to disambiguate which host the client wishes to talk to. As presently worded, it seems like bar.com<http://scanmail.trustwave.com/?c=4062&d=-afK1aJC190ZIBtTTWDRZJ2ezKF8D9uNVrI5HuDs3Q&s=5&u=http%3a%2f%2fbar%2ecom> MAY be able to apply for a certificate for foo.com<http://scanmail.trustwave.com/?c=4062&d=-afK1aJC190ZIBtTTWDRZJ2ezKF8D9uNVuJuGOy9jA&s=5&u=http%3a%2f%2ffoo%2ecom>.

Now, I know that's not the intent, but that strikes me as an area that needs further clarification about what "controls an IP address" means (e.g. does it mean looking in the appropriate RIR for that Netblock and confirming the applicant through a Reliable Means of Communication?)

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150507/a402e32f/attachment-0003.html>