[cabfpub] Domain validation

[kirk_hall at trendmicro.com]

Well said, Tim.  All the other practical demonstration methods (6-9) are effectively “challenge and response” mechanisms involving both the CA and Applicant, and all are pretty clear as to who, what, where, how – How is the Random Value transmitted to the Applicant, where is the Random Value placed on the Applicant’s website, who does it (for the other methods, it is the Applicant – for method 10?), even what is the exact means by which the CA verifies the Random Value was placed in the right place.

For method 10, those specifics are missing.  They need to be added or else we can’t evaluate the security of the method – and ambiguity could allow some CAs to misinterpret and implement an unsecure method.

Here is the current language that needs to be made much more specific (sorry for the haiku format, but it makes it easier to analyze this way):

Having the Applicant demonstrate control over the FQDN
by providing a TLS service on a host found in DNS for the FQDN
and having the CA
(i) initiate a TLS connection with the host and
(ii) verify a Random Value that is a in a format recognized as a valid TLS response.

Doug mentioned a different verification method where the CA sends the customer a cert from a private (untrusted) root and asks the customer to install on the FQDN being verified, then confirms it is there and issues a production cert.  Doug – can you write that up as “new” method 9 (as we have no method 3 in the current draft – we can renumber current 4-9 to be 3-8, and insert your new method as method 9)?

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek
Sent: Thursday, May 07, 2015 1:09 PM
To: Ryan Sleevi
Cc: CABFPub
Subject: Re: [cabfpub] Domain validation

In the #10 use case Gerv was discussing, the certificates are self-signed, so the TLS-ness doesn’t provide much value, so it doesn’t matter where the TLS terminates.  If we’re going to allow that, I think we should make it explicit what we’re allowing (self-signed or untrusted certificates), and also enforce the .well_known requirement for the same reasons why we did it for #6.

However, on the validation working group call, another use case was discussed, where validation *does* matter, however the validation is against a non-publicly trusted root (basically, the web site installs a test cert to prove they control the certs for the domain).  It’s an interesting use case that I think should be allowed, though I think it should be a separate enumerated method because the security model is different.

I think #10 needs to be tightened up and clarified significantly.  I’m sure this will be discussed extensively on the validation WG call in two weeks.

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, May 07, 2015 12:07 PM
To: Tim Hollebeek
Cc: CABFPub; Anoosh Saboori
Subject: RE: [cabfpub] Domain validation


On May 7, 2015 6:47 AM, "Tim Hollebeek" <THollebeek at trustwave.com<mailto:THollebeek at trustwave.com>> wrote:
>
> 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
>

No Tim, they aren't equivalent under the threat model / equivalency that Anoosh agreed as (part of) the concern.

In both the Azure and the AppEngine case, the hosting provider terminates TLS, and thus the tenant cannot influence it.

This isn't universal for all hosting scenarios (e.g. Google Compute Engine, AWS), but it does represent a material difference to the threat model that we should not consider them equivalent.

________________________________

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.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150507/4d7f70d5/attachment-0001.html