[cabfpub] Continuing the discussion on CAA

Rick Andrews Rick_Andrews at symantec.com
Tue Oct 25 21:38:14 UTC 2016

Ryan, I don’t think it makes sense to me, but to be fair, it might be due to my limited knowledge of DNS. As for technical complexity, it seems simpler than CT ;^)


I wasn’t proposing re-implementing DNS within our validation infrastructure. As far as I know, we already have recursive resolvers in our infrastructure (I think they’re also called stub resolvers), and again, as far as I know, they implement caching according to the DNS spec. Even if we didn’t have recursive resolvers in our infrastructure, and we used, say, Google’s, isn’t that also a recursive resolver that caches? Consulting my internal recursive resolver will be a bit faster than consulting one outside of my infrastructure, but it seems to me that the net effect is the same; caching prevents clients from seeing immediate changes made at the authoritative name servers. 


Which concerns of Jacob’s are you’re referring to? The fact that LetsEncrypt does CAA checking at validation but not issuance time because it’s too expensive?


It sounds like your ideal case would require everyone to use DNS in a way that it wasn’t intended to be used (no caching). That makes me think that DNS isn’t the best place to keep this type of info, but I can’t think of a better place.




From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Tuesday, October 25, 2016 11:55 AM
To: Rick Andrews <Rick_Andrews at symantec.com>
Cc: Gervase Markham <gerv at mozilla.org>; public at cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA


As mentioned during the meeting, this doesn't sound fundamentally problematic, just exceptionally technically complex - and we know that the greater the technical complexity, the harder it is for CAs to implement.


It's unclear whether your proposal is, in effect, suggesting that CAs should "re-implement" DNS within their validation databases. Isn't an alternative solution for the CA to run a recursive resolver within their infrastructure, have their CAA lookups utilize this internal recursive resolver (either immediately or within some tightly-bounded time, as appropriate for operational concerns), and then allow that recursive resolver to properly implement the DNS RFCs (which includes caching based on TTL)


I think this would split the difference between the concerns you raised, and Jacob raised, in as much as you still benefit from the 'don't communicate with outside services' goal, by utilizing a CA-maintained recursive resolver that strictly implements the DNS specification, while also allowing some flexibility with the integration of the systems.


Certainly, my 'ideal' world would be no 'implicit' caching (that is, always "check" CAA at issuance time), but for which CAs can utilize a recursive resolver as part of their CA infrastructure, and that recursive resolver implements any DNS-defined caching semantics. This at least gives relying parties - and perhaps more importantly, auditors - objective criteria for which they can threat model and evaluate these systems.


Does that make sense?


On Tue, Oct 25, 2016 at 11:43 AM, Rick Andrews <Rick_Andrews at symantec.com <mailto:Rick_Andrews at symantec.com> > wrote:

Ryan, one week may be appropriate for reuse of cached CAA records, but during the face-to-face meeting in Redmond, I realized that the time-to-live (TTL) of the CAA record could make that completely ineffective.


RFC 6844 doesn’t provide guidance on what TTL should be used on a CAA, but if a domain owner sets a TTL longer than one week, repeated checks by the CA would be served from cache and wouldn’t be served from the authoritative name server.


What do you think of allowing the CA to cache the CAA record for the TTL specified in the record? We could augment that with instructions to domain owners to pay careful attention to the TTL they specify in their CAA records.




From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ] On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, October 25, 2016 8:22 AM
To: Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org> >
Cc: public at cabforum.org <mailto:public at cabforum.org> 
Subject: Re: [cabfpub] Continuing the discussion on CAA




On Tue, Oct 25, 2016 at 1:57 AM, Gervase Markham via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

I think this is definitely worth exploring, and I am confident we can
work out some reasonable parameters. However, I wonder if, if we are not
checking CAA at every issuance, it would be wise for CAs to be required
to implement a "no more certs, please" procedure where the customer can
tell the CA to throw away all cached validation information, including
the CAA check results. This could be automated in circumstances where
the customer has a login.


I think it may also be useful to do this for non-customers, but domain holders.


Consider the following certificate: https://crt.sh/?id=35360532


It was issued 2016-09-26 to a customer on Google service's

Since roughly 2016-03-31, googleusercontent.com <http://googleusercontent.com>  has had a CAA record of 0 issue symantec.com <http://symantec.com> 


So why was this certificate issued? Well, as Jacob mentioned in https://cabforum.org/pipermail/public/2016-October/008576.html , Let's Encrypt checks CAA at validation time, not issuance time. Despite our CAA record helpfully preventing any new validations, this particular user had a pre-existing cached validation, according to Let's Encrypt, and so the new certificate was issued using the pre-existing validation.


Ironically/unfortunately, it was this pre-existing validation ( https://crt.sh/?id=14639682 ) that lead us to place CAA on the domain to begin with.


Now, I'm not suggesting Let's Encrypt has misissued this certificate - it's why I've been continuing to call it 'unauthorized' issuance - and with respect to the BRs, everything LE did was correct. In particular, the re-use of cached information is fully permitted in the BRs (as many CAs know). However, from a our perspective, this was certainly 'a surprise' and not intended.


So if we're going that route, I do believe we need to set a much tighter upper-bound than the currently permissible 39 months. Unlike WHOIS information, for which we know some registrars don't provide or some registries make it considerably more difficult (c.f. the CAPTCHA/OCR issues of Comodo recently), CAA is something that any domain holder can express or maintain themselves, and any CA can query.


So it seems like one week or so should be the upper-bound to how long this information can be re-used.


As for how we're dealing with this unauthorized issuance, at least with an LE model, we need to submit every one of these 'unauthorized' certificates as problem reports, and hope that Let's Encrypt agrees with us on the basis of domain holder, and then hope that the associated cached data is thrown away. Further, for what it's worth, the BRs do not require that such cached info be thrown away on a problem report - that's simply Let's Encrypt going above and beyond the BRs to do what is common sense and necessary for security, and which other CAs may not be at that same level of maturity.


> 2) If a customer has a single base domain and needs to issue 6 million certs
> an hour for the various sub domains, then there isn't a way for the CA to
> simply accept the base domain's CAA record.

I'm not sure how to address this without changing the way CAA works.
AIUI it's specced to work from the requested domain down to the root. So
I'm not sure I'd say this problem is "easily solved". Does PHB have a


I'm not PHB, but you're absolutely correct that it's "not how CAA works". 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161025/3ec2cb76/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5725 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161025/3ec2cb76/attachment-0001.p7s>

More information about the Public mailing list