[cabfpub] Revisiting CAA

Tue May 6 00:09:20 UTC 2014

On Sat, May 3, 2014 at 9:28 AM, kirk_hall at trendmicro.com <
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?
>

Because, as I mentioned in my email, it's not working well at filtering out
illegitimate requests, and it only benefits Google because Google is Google
(aka a High Risk Target).

>
>
> 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.
>

That's true, if your customers cannot manage their infrastructure.

You already have the counter-story for where it provides real benefits to
real users, a value that would seem to outweigh this hypothetical risk.

>
>
> 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 <
> 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]
>
> Sent: Friday, May 02, 2014 10:54 AM
> To: Gervase Markham; Kirk Hall (RD-US); Rick Andrews; 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 ; Rick Andrews ; public at cabforum.org
> Subject: Re: [cabfpub] Revisiting CAA
>
> On 02/05/14 16:40, 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
> 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
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140505/f3e0558f/attachment-0003.html>