[cabfpub] CNAME-based validation

Wed Sep 7 00:07:03 UTC 2016

Hi Ryan, 

Pardon my DNS ignorance, but how does the server know which CNAME record to use in this case? If shop.domain.com CNAMEs to digicert.com and *.domain.com CNAMEs to google.com, then how do you know which will resolve? There isn’t a weight/ordering preference for CNAME like there is TXT records.  

As for how to resolve this, what if the CA generated two random numbers, holding one of the numbers in reserve. Immediately after verifying that <rnd1>.domain.com CNAME points to a validated domain, the CA can then check <rnd2>.domain.com to see if it resolves. If it resolves successfully, a wildcard DNS is in place and the domain is not validated. If the domain does not resolve, a wildcard DNS is not present and the domain is considered validated. Does this resolve your concern?

Jeremy

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Friday, September 2, 2016 7:40 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: Peter Bowen <pzb at amzn.com>; public at cabforum.org
Subject: Re: [cabfpub] CNAME-based validation

Hi Jeremy,

I'm afraid you may have misread my example.

shop.example.com <http://shop.example.com>  is a CNAME to paymentprovider.example.org <http://paymentprovider.example.org>  (curse our lack of distinct TLDs). It does not resolve to example.net <http://example.net> 

On Fri, Sep 2, 2016 at 6:29 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Here’s the steps:

1)      CA verifies example.net <http://example.net>  using any one of the methods permitted

2)      CA receives request for shop.example.com <http://shop.example.com> 

3)     CA retrieves CNAME for shop.example.com <http://shop.example.com>  (permitted under Authorization Domain Name definition: “The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation”)

4)     CNAME causes resolution to example.net <http://example.net> . 

5)     Example.net is verified under step 1, permitting issuance of the certificate 

From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Friday, September 2, 2016 5:12 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
Cc: Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >; public at cabforum.org <mailto:public at cabforum.org> 

Subject: Re: [cabfpub] CNAME-based validation

Right, and I'm not sure that (2) sufficiently establishes that example.com <http://example.com>  is authorizing the request, given wildcards.

I think this would be a similar concern with, say, following HTTP open redirects and saying a "200 OK" code authorizes the request - wellllll, not really.

I'm curious if you could expand more why you believe other methods would permit a cert to be issued in the presence of this Wildcard DNS.

As a concrete example:

example.com <http://example.com>  A [my host]

*.example.com <http://example.com>  CNAME example.net <http://example.net> 

shop.example.com <http://shop.example.com>  CNAME paymentprovider.example.org <http://paymentprovider.example.org> 

Under this scenario, could you explain what ways that the [<rnd>.example.com <http://example.com> ] would be able to issue a cert for either example.com <http://example.com>  or shop.example.com <http://shop.example.com>  ? Perhaps I'm just missing the implications of the existing validation methods.

On Fri, Sep 2, 2016 at 3:33 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

Yes. Those are the two steps I am proposing.

-----Original Message-----
From: Peter Bowen [mailto:pzb at amzn.com <mailto:pzb at amzn.com> ]
Sent: Friday, September 2, 2016 4:31 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >

Cc: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; public at cabforum.org <mailto:public at cabforum.org> 
Subject: Re: [cabfpub] CNAME-based validation

I think you are talking about two different things.

Ryan is concerned that a customer has an existing record that is “*.example.com <http://example.com>  CNAME vanityblogs.example.net <http://vanityblogs.example.net> ”.  If you say “if you can make a record show up at _309654fddb59444d8efd6d2cc98881d5.example.com <http://309654fddb59444d8efd6d2cc98881d5.example.com>  you are validated” that is bad.  Instead, you are proposing a two prong validation test:

1) Confirm control of vanityblogs.example.net <http://vanityblogs.example.net> .
2) Make _309654fddb59444d8efd6d2cc98881d5.example.com <http://309654fddb59444d8efd6d2cc98881d5.example.com>  point to vanityblogs.example.net <http://vanityblogs.example.net> .

You are proposing that passing these both would confirm control of example.com <http://example.com> , right?  And this would allow getting a certificate for shop.example.com <http://shop.example.com> , correct?

Thanks,
Peter

> On Sep 2, 2016, at 3:25 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:
>
> We are talking about the same thing (wildcard DNS records).
>
> Examples:
>
> sleevi.example.com <http://sleevi.example.com>  CNAME vdomain.com <http://vdomain.com> 
> *.example.com <http://example.com>  CNAME vdomain.com <http://vdomain.com> 
> <rnd>.example.com <http://example.com>  CNAME vdomain.com <http://vdomain.com> 
>
> The BRs permit verification of each of these by establishing control over vdomain.com <http://vdomain.com>  (under the definition of authorization domain name).
>
> If *.example.com <http://example.com>  can be verified this way, what is different between verifying *.example.com <http://example.com>  and <rnd>.example.com <http://example.com>  to verify all sub domains of example.com <http://example.com> ? All the RND does is make it so the website doesn’t have to point to vdomain.com <http://vdomain.com> .
>
> Jeremy
>
> From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>  [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ]
> On Behalf Of Ryan Sleevi
> Sent: Friday, September 2, 2016 4:05 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
> Cc: public at cabforum.org <mailto:public at cabforum.org> 
> Subject: Re: [cabfpub] CNAME-based validation
>
> Jeremy,
>
> Perhaps it wasn't clear, I wasn't speaking of wildcard certificates, but wildcard DNS rules, in which all requests for a given subdomain return a preconfigured record type. While for TXT and CAA records this is quite uncommon, it's exceedingly common to have CNAME records.
>
> That is, both <rnd>.example.com <http://example.com>  and sleevi.example.com <http://sleevi.example.com>  may both CNAME to example.com <http://example.com> , by virtue of of the host putting a rule of "*.example.com <http://example.com>  3600 CNAME example.com <http://example.com> "
>
> I am attempting to assert that placing the <rnd> in the subdomain is insufficient proof of authorization, and is meaningfully and tangibly different than the proof of control demonstrated in 3.2.2.4.7.
>
> As I read your wording, it suggests the following:
> CA looks up <rnd>.example.com <http://example.com> 
> <rnd>.example.com <http://example.com>  points to example.com <http://example.com>  CA sees it previously issued a
> certificate for example.com <http://example.com>  using one of the other methods CA issues
> certificate for <rnd>.example.com <http://example.com> 
>
> That concerns me.
>
> Peter's rewording suggests the inverse:
> CA looks up _certvalidation.example.com <http://certvalidation.example.com>  _certvalidation.example.com <http://certvalidation.example.com> 
> points (CNAMEs) to <rnd>.validation.[nameofca].com CA issues
> certificate for example.com <http://example.com> 
>
> This is much less concerning.
>
> Could you help clarify which you intend, and for what names/purposes?
>
>
> On Fri, Sep 2, 2016 at 2:52 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:
> Wildcard domains are already allowed. We can verify Wildcard DNS because a CNAME for *.domain.com <http://domain.com>  is pointing to a record previously verified. This verification method is permitted under the definition of Authorization Domain Name (where the FQDN returned by a CNAME lookup can be used to verify the requested FQDN). Although <rnd>.domain.com <http://domain.com>  isn’t necessarily distinguishable from *.domain.com <http://domain.com> , the validation ends up being the same because either its considered an Authorized Domain Name (under the definition) or it was validated as a random value in this new method.
>
> For example:
>
> *.domain.com <http://domain.com>  -> dcv.example.com <http://dcv.example.com>  (validated under the Authorized Domain
> Name section) <rnd>.domain.com <http://domain.com>  ->validation.example.com <http://validation.example.com>  (validated
> under this new section)
>
> Because each is validated properly, tracking which exact section was used in the validation isn’t necessary.
>
> Jeremy
>
> From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ]
> Sent: Friday, September 2, 2016 3:28 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> >
> Cc: public at cabforum.org <mailto:public at cabforum.org> 
> Subject: Re: [cabfpub] CNAME-based validation
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org> 
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160907/39bae1fa/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160907/39bae1fa/attachment-0001.p7s>