[cabfpub] Revisiting CAA

Sat May 3 10:35:54 MST 2014

Some CAs are domain registrars some, others are not. What if some of 
those registrars offer also "free CAA service"?

Thanks,
M.D.

On 5/3/2014 7:28 PM, kirk_hall at trendmicro.com wrote:
>
> Well put, Ryan -- but I would point out that the "variety of requests 
> for confirmation from CAs that we [Google]  do not do business with 
> about the legitimacy of certain requests" you mention below sound like 
> the results of the vetting process itself -- and the vetting process 
> appears to be working well at filtering out illegitimate requests.  
>  Why add yet another step?
>
> No one can identify any mis-issued certs from the past decade that 
> would, in fact, have been prevented by CAA.  Current vetting practices 
> are working.  They can be strengthened if needed, but until we find 
> cases of CA mis-issuance after vetting, the current practices seem to 
> be working well.
>
> CAA clearly is an impediment to competition among CAs, and imposes 
> another administrative and engineering burden on cert issuance.  And 
> yet there are no real business rules around what to do with a contrary 
> CAA result after completion of all vetting for a cert request (using a 
> third party confirmed phone number to call "Google, Inc.," checking 
> WhoIs, etc.  I can predict with confidence that many large 
> organizations will lose track of who is maintaining the CAA records in 
> various hosting locations, and how to make a change.  The CAA record 
> will then become inaccurate and out of date.  Someone who is 
> authorized to buy certs for a company then signs a deal with a new CA 
> (at a better price and service level), but the contrary CAA record is 
> found.  Either the parties ignore the record as "something we'll clean 
> up later" or the deal is delayed or prevented because no one can get 
> the CAA record updated. Either way, after proper vetting of a cert 
> request by an organization the CAA record is not very useful.
>
> CAA strongly favors incumbent CAs, for little or no demonstrated value 
> to the security structure (especially as each CA gets to craft its own 
> response or non-response to a CAA record). It also lacks DNS support. 
>  To me, it has more potential negative aspects than positive.
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Friday, May 02, 2014 6:15 PM
> *To:* Kirk Hall (RD-US)
> *Cc:* Gervase Markham; public at cabforum.org
> *Subject:* Re: [cabfpub] Revisiting CAA
>
> Kirk,
>
> Your parenthetical comment leaves me believing you still do not see 
> the significant value of CAA. Allow me to attempt to explain.
>
> Considering that, at it's most basic level, a certificate is a binding 
> to a DNS record - which is a perfectly acceptable form of validating 
> the legitimacy of the request (according to the BRs), there is no 
> entity more authorized to make decisions on certificate purchases than 
> the DNS operator.
>
> At Google, we have received a variety of requests for confirmation 
> from CAs that we do not do business with about the legitimacy of 
> certain requests. It's not uncommon to see these requests generated by 
> acquisitions, but can also be generated inhouse. There are several 
> means for an applicant to satisfactorily demonstrate control without 
> the involvement of the DNS operator - Options 1, 6, and 7 of Section 
> 11.1.1 of BRs 1.1.7. While these requests are not in line with our 
> internal policies, they are made, and CAs receive them, and with 
> respect to the BRs, they are "valid requests".
>
> Because Google is (fortunately?) a high-value target, such requests 
> are (almost always, unfortunately) deemed High Risk Requests (Section 
> 11.5), and thus either those of us involved in the CA/B Forum, or our 
> Security team, or our DNS operations team will receive a confirmation 
> of the request - for which we always respond "NO"
>
> CAA - if it is actually respected - would allow us to centrally 
> announce our issuance policies (since we centrally manage the DNS for 
> these acquisitions), and potentially avoid this entirely. Of course, 
> that's assuming the CA is concerned about safety and reputation and 
> performs meaningful actions with such signals (eg: treating as a high 
> risk request).
>
> Now, for all the other organizations - whether they be smaller, 
> larger, or the same size as Google - who deal with these same problems 
> (again, Options 6 and 7 are huge enough holes that any competent 
> social engineering/sob story could drive right through) can benefit, 
> even if they're not already on the CA's high risk target list.
>
> In my view - every one of those requests (... including those that 
> were, unfortunately, satisfied) - would count as a misissuance. 
> Unfortunately, because we lack solutions like CT in active deployment, 
> it's hard to quantify those - and even harder, since those most 
> affected by it neither participate nor have a voice here.
>
> On Fri, May 2, 2014 at 5:54 PM, kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com> <kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com>> wrote:
>
> Another concern we have with CAA (apart from the fact that it would 
> not have avoided any known cases of certificate mis-issuance in the 
> past) is that often in larger companies (the most typical fraud 
> targets), the person who buys the certs is not the person who manages 
> the DNS -- and often, the person who buys the certs doesn't even know 
> who is managing the DNS.
>
> Gerv -- at one point, you were going to conduct a test within Mozilla 
> on this point -- how easy/hard was it to get CAA notations put in the 
> proper DNS records, and how easy was it to coordinate the buyer(s) of 
> certs for Mozilla with the various people in charge of the DNS for 
> Mozilla's websites.  As I recall, you found it somewhat difficult to 
> discover and coordinate the two groups.  Is that correct?
>
>
> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:philliph at comodo.com 
> <mailto:philliph at comodo.com>]
>
> Sent: Friday, May 02, 2014 10:54 AM
> To: Gervase Markham; Kirk Hall (RD-US); Rick Andrews; 
> public at cabforum.org <mailto:public at cabforum.org>
> Subject: Re: [cabfpub] Revisiting CAA
>
> Gerv makes a good point. But I will point out that the reason the CAA 
> spec says nothing about what the CA has to do in response to a 
> non-compliant request is that the IETF is the wrong forum to discuss 
> such issues.
>
> What approaches are appropriate are going to depend on takeup by the 
> domain name holders and what attacks we see. those will change over 
> time. So CABForum is a better place to discuss such issues.
>
> -----Original Message-----
> From: Gervase Markham
> Sent: Friday, May 02, 2014 11:54 AM
> To: kirk_hall at trendmicro.com <mailto:kirk_hall at trendmicro.com> ; Rick 
> Andrews ; public at cabforum.org <mailto:public at cabforum.org>
> Subject: Re: [cabfpub] Revisiting CAA
>
> On 02/05/14 16:40, kirk_hall at trendmicro.com 
> <mailto:kirk_hall at trendmicro.com> wrote:
> > Can anyone identify one case -- even one -- of mis-issuance of a
> > certificate by a CA that would have been prevented by CAA?  (I can't
> > think of one.)
>
> It depends how CAs implement CAA. If the CA implements CAA as, among 
> other things, a separate automated sanity check on all certificates, 
> just before they go out the door, using an isolated system - and certs 
> which fail have to be manually approved - then I can see it catching 
> several of the recent misissuances.
>
> If the CA implements CAA as a printed warning on the certificate 
> issuance screen that the operator can choose to deal with or ignore, I 
> imagine it would catch fewer misissuances.
>
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
> <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>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
> 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.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140503/1eca47e3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3663 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20140503/1eca47e3/attachment-0001.bin 