[cabfpub] Continuing the discussion on CAA

[Ryan Sleevi]

On Mon, Oct 24, 2016 at 12:09 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
wrote:

> Yes, please provide the links to all – I certainly don’t remember any
> details from what you have said in the past, and others feel the same way.
> I promise I will read the links carefully for the details you have
> provided.
>

Considering that you actively participated in a discussion about this, less
than a week ago, and that we've previously discussed this on calls, you've
really exhausted all good faith for participating in these discussions.


> But I have to say, Ryan, it’s not useful when you always say “I answered
> that before” instead of going ahead and answering it again – just humor us,
> please.
>

Kirk, it's not useful when you can engage in a discussion, and within days
of it completing, ask the same question and be ignorant of the discussion
you participated in.

Perhaps it would be better if you wait for the minutes to be posted, so you
can remember what you asked, and how you were answered.


> You and others are asking a lot of CAs when you push us to hard stop on
> CAA, so you really owe it to all of us to be patient and try to persuade us
> your preferred course of action is, in fact, a good idea.
>

Well, as Gerv said, I think an alternative is for root programs to mandate
this.

We've been discussing this for years. You've continued to use this argument
time and time again, and every time it's answered, in good faith, you then
wait a few weeks, and ask it again. It's incredibly disrespectful - and
suggests you either don't care about the response or don't care to engage
in good faith.

I've been debating CAA with you for over two years - consider posts like
https://cabforum.org/pipermail/public/2014-May/003291.html or your strawmen
like
https://cabforum.org/wp-content/uploads/Current-State-of-CAA-Sep2014.pdf ,
or attempts at things like
https://cabforum.org/pipermail/public/2014-September/003843.html .

You've tried to ask variations of this question before - consider
https://cabforum.org/2015/10/29/2015-10-29-minutes/

But since you're going to continue this line of inquiry, let me restate to
you what was shared at the F2F:

You asked, during the F2F, whether any CA's had been prevented of
misissuance. When I attempted to respond, you got upset, feeling that I was
interrupting you and asked to be allowed to finish your question. You then
further re-iterated your desire to understand third-party issuance cases. I
described to you two types of unauthorized issuances, to third-parties,
that had been observed by members in the room.

One example discussed was googleusercontent.com, which allows third-parties
to host content, but for which TLS termination is always handled by Google.
In this case, users were able to obtain certificates from Let's Encrypt,
because we lacked CAA records at the time, but allowed user content on some
sub-domains for this domain.

I then pointed to Peter, and discussed that Amazon had encountered a nearly
identical situation with Amazon AWS, which also provides TLS termination
for the clients. Amazon lacked CAA records, and customers were able to
obtain certificates from WoSign, using WoSign's file-based validation
method.

In the case of Google domains, we went and added CAA records to our
properties, which has prevented unauthorized issuance. I was precise in my
terminology here - unauthorized - because it's not authorized by the domain
holder, even if it's valid according to the language of Section 3.2.2.4

During this discussion, I engaged with Bruce Morton, your colleague, to
discuss how CAA is complementary to what is already afforded in the BRs,
but due to a wording error, seen as nuance. That is, if you have a
pre-existing relationship with a CA, you can define a set of authorized
requestors, but you cannot do so unless and until the CA has already issued
a certificate for your domain. This was seen, by members in the room, as
'unintentional' - that is, that the intent was to cover both cases. Bruce
and I, with microphones, discussed the challenges that a CA would have
processing such requests, and where CAA affords a technical solution to a
problem that was incompletely solved via policy.

Later on in that day, during the same discussion, while you were also
present, with Jeremy standing up with a microphone, with Peter having the
microphone that offered feedback, and with me in the back with a
microphone, we discussed how 3.2.2.4's different means of authorizing
requests provide different levels of assurances. This was during the
discussion about whether the "domain admin" has the authorization to
express such policy. After Alex Wright pointed out that the domain admin
already has great capability to exceed the policy, Peter pointed out that
not all authorization methods used DNS, and that DNS is not in a special
position with respect to issuance. I disagreed with Peter, pointing out the
case raised by Anoosh at Microsoft during Anoosh's time participating, with
the previously-numbered method 6 of the validation WG proposal (the
.well-known method). As you may recall, both Google and Microsoft expressed
some concerns that the file-based validation offers less assurance of
authorization than the other methods, and that even the e-mail or whois
validation methods relied ultimately on the DNS. This then continued into a
nuanced discussion about how domain holders may register domains, providing
WHOIS information, without actually providing DNS information - as Peter
described it, "parking" domains.

I highlight this entire conversation, which I have no issue recalling and
hope it is minuted, because it was during this discussion I again raised
the case of hosting providers, this time using the examples Anoosh provided
with respect to Azure, and Microsoft's desire to be able to restrict
file-based validation methods from being used for their domain.

I hope you consider this sufficient at humouring you, even if it's as
flawed a question as "When did you stop beating your spouse?", in the hopes
that we can move past this otherwise unproductive line of questioning,
given that so few CAs respect CAA. It's irrelevant and unhelpful, because
it's asking "How is CAA useful, when CAs keep trying to stall, ignore, or
cripple it?" And the answer is - if it's not useful, it's because CAs keep
trying to stall, ignore, or cripple it.

I'm totally happy to engage in the discussion of use cases, failure modes,
and benefits, but not if within the span of days, conversations for which
you were directly engaged in can be so conveniently forgotten and ignored,
and thus repeated. That's a surefire way to ensure your contributions and
questions are ignored in the future.


> I would just point out that when you say “you are tired of getting calls”
> from CAs,
>

I would just point out that you're putting words in my mouth.


> that also implies that the current method of vetting a certificate request
> (contacting the alleged customer through a third party phone number, etc.
> to make sure the certificate request is authorized) is *working*, and
> might not be made any safer by reference to a CAA record.
>

This is, of course, false, and has been addressed at such for over two
years. I can find archives in both May and September of 2014 in which we
discussed this, and Eric Mill specifically responded to this during the
F2F. For the sake of humouring you, I will paraphrase Eric's point made,
which is that CAA allows for an equitable treatment of all requests as
high-value, rather than CA-defined policies that are inconsistent and
opaque.

I described to you, using the example of a request GoDaddy received from a
Google Ventures/Alphabet company, the challenges that a CA can face when
escalating this, and the inconsistency that can arise, both for CAs and for
the domain holders.

I appreciate your consideration of this topic, but I do not appreciate how
you can actively engage in conversation, but then present it as innocently
forgetting, especially not when you've been opposing CAA for over two years
now, as the records show. It appears to be a stalling form, at this point,
rather than honest engagement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161024/4adb61c4/attachment.html>