[cabfpub] Revisiting CAA
Moudrick M. Dadashov
md at ssc.lt
Sat May 3 17:35:54 UTC 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: <http://lists.cabforum.org/pipermail/public/attachments/20140503/1eca47e3/attachment-0003.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: <http://lists.cabforum.org/pipermail/public/attachments/20140503/1eca47e3/attachment-0001.p7s>
More information about the Public
mailing list