[cabfpub] Revisiting CAA

Tue May 6 06:12:06 UTC 2014

On May 5, 2014 11:01 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>
> Well, unless there is more information you can share, I don’t think
that’s correct.
>
>
>
> If any CA gets a cert request for a domain that is registered to Google,
first they verify that the organization exists, and then they call the
organization though a phone number (for Google) verified by a third party
data source.  That’s OV vetting.  EV vetting is more complex.
>
>

Kirk,

OV is useless here for the discussion, except as a distraction. As I
mentioned in the previous mail, all that matters here is what the BRs
require - and that is not enough.

>
> Is that the phone calls you are receiving?  Regular vetting?  If yes, it
sounds like vetting is working.  If not, can you explain?
>

No. You can see I have already addresses this in the previous message about
precisely where and how this fails. I'm happy to address any confusion you
may have from that message.

Note that OV is a concept that some CAs promote, but is completely
inconsequential for users or their security. This is and should remain a
discussion about the normative requirements of DV, as expressed in the BRs.

>
>
> Of course, most or all CAs will add extra verification steps for high
risk targets, like your company and all the other browsers on this list.
That will typically flag extra verification steps.
>

And, as I already addresses in the previous message, it is a great
disservice to the online community and their security that there is no way
for site operators to 'opt-in' to this high risk treatment. Among the many
other benefits of CAA, it provides an unambiguous signal that the site
operator desires this treatment from CAs, and a great shame if a CA
structures their CPS to ignore such a request.

The CA ecosystem is only as strong as the weakest link, unfortunately, and
in a land of changing threats, we should be more receptive to techniques
that empower site operators to be more expressive about their security
policies - such as HTTP Strict Transport Security, Public Key Pinning, and,
yes, CAA.

>
>
> If you are receiving calls that indicate the combination of regular OV
and EV vetting, plus the special steps that CAs take to deal with high risk
targets like the browsers (as prescribed by the BRs and EVGL) is NOT
sufficient, can you share some information with the Forum?  We can then
consider if the vetting steps are not sufficient.
>
>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Monday, May 05, 2014 5:09 PM
>
> To: Kirk Hall (RD-US)
> Cc: Gervase Markham; public at cabforum.org
> Subject: Re: [cabfpub] Revisiting CAA
>
>
>
>
>
>
>
> 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.
>
>
>
> 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/513a6740/attachment-0003.html>