[cabfpub] Ballot 187 - Make CAA Checking Mandatory

[Ryan Sleevi]

On Sat, Feb 25, 2017 at 5:20 PM, Peter Bowen <pzb at amzn.com> wrote:
>
> Consider Public Key Pinning for HTTP.  If example.com sets a pin with
> “includeSubdomains”, then it applies to shop.example.com.  If
> shopcorp.example set a pin with includeSubdomains it does not apply to
> shop.example.com.  If example.com is pinning a CA key, they probably want
> to have a matching CAA record to help avoid confusion — they want the cert
> request rejected if they know resulting certificate isn’t going to work.
>

For what it's worth, it's this behaviour that has been a significant
blocker for sites deploying PKP, at least as part of the ongoing evangelism
and discussions we've done during and following standardization.

I agree there's an asymmetry to PKP, but I also think that CAA offers a
far, far more compelling solution than PKP, and so I'd rather make sure we
get it right the second time :)


> I agree that your example could make sense, but it makes no sense in the
> common CDN case, as the CDN is just doing byte serving.  The CDN probably
> does TLS decryption, but it might not; it would be very possible that the
> “CDN” is really just a better network that gets the encrypted packets to
> the origin server faster than would happen via the public internet.  For
> example, you could be using Google Cloud Load Balancing in TCP mode. In
> this case there is zero reason for the CDN’s domain setting to control
> certificate issuance.
>

Indeed, while some CDNs simply backhaul the connection on their own fiber
versus relying on (unreliable) exchanges, I would again suggest the
majority service here is that the CDN is doing the certificate issuance
(... and also commonly the domain management).

I think we're actually in agreement in that these are somewhat conflicting
goals, and I raised the example as it sounded like you hadn't considered
it, when you mentioned it wasn't logical to behave like that. It is
logical, but it's a question about which case to optimize for - again,
acknowledging the tradeoffs involved here.

The reason for which I take the position I do - that is, the
recurse-into-alias-before-resuming approach (as I believe it specified /
intended to be)  - is that by adopting the PKP-like top-down approach, then
it means any time you want to introduce a CDN or point of delegation (who
might use MegaCA), you need to allow MegaCA for your entire domain
hierarchy at the upper levels. You can kinda work around this (e.g.
shop.cdn.example.com, where shop is a CNAME, but there's a CAA record for
cdn.example.com that is different than the CAA record for example.com), but
then that puts more burden on the site operator to update when the CDN
makes operational changes.

By going the approach I suggest, it means you only introduce any additional
'risk' to the ecosystem when a site operator introduces CNAMEs. Since I
take the view that CDNs are already an additional threat vector regardless
of CAA, and further that CNAMEs are most commonly to support CDNs, then I'm
ok with the loss of absolute control that it affords the example.com
operator, because I think they've already lost control.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170225/d2450435/attachment-0003.html>