Re: Skipping DNS resolutions with ORIGIN frame

On Tue, Jul 18, 2017 at 7:29 PM, Watson Ladd <watson@cloudflare.com> wrote:

> On Tue, Jul 18, 2017 at 2:23 PM, Mike Bishop <Michael.Bishop@microsoft.com
> > wrote:
>
>> Unless the cdnjs.cloudflare.com is in the same cert, you’d also need the
>> Secondary Certificates extension to support that.  Once it’s there, though,
>> I think the discussion is the same whether we have multiple certificates or
>> one – we have a single factor (the certificate) that claims authority for
>> some other name.  How do we reach a sufficient level of trust?  DNS is a
>> weak second factor; are there other second factors we would be willing to
>> consider as equivalent?
>>
>
> We can put it in the same cert for a lot of our customers and Secondary
> Certificates is also on the roadmap for this.
>
> It depends on what we want to guard against. If it is just mississuance,
> presence of the certificate in CT logs is fine. If we're concerned about an
> attacker with the private key of the certificate, then presence of the
> certificate in the CT logs isn't enough and DNS provides an extra fig-leaf.
>
> A lot of the proposals being discussed aren't detailed enough for me to
> say if they would work or not for us. Would it be enough to have every site
> Alt-Svc cloudflare.com (easy), or would the Alt-Svc proposals end up N^2
> scaling (nonstarter)? Our IPs aren't shared between sites in any sort of
> regular pattern and which one is used by customer.example.com can change
> for various reasons.
>
> We can't have cdnjs.cloudflare.com advertise every single customer as an
> Alt-Svc.
>
>>
Strawperson:  if every one of a CDN's sites (including cdnjs.example.com)
did an:

                  Alt-Svc: h2="cdn.example.net:443"; ma=7200; coalesce=1

then one might argue that there is a positive indication from a strongly
authenticated origin (where DNS was followed initially to receive the
Alt-Svc)
saying that connections to cdn.example.net can safely coalesce as long as
there is cert coverage.
ie, if the cert presented when connecting to cdn.example.net and sending
SNI="www.example.com" covers "www.example.com", or if such a cert
is pushed via Secondary Certificates down the road.

It may be that to make this really useful, clients may want to be able to
probe
for a Secondary Cert + ORIGIN to be sent to them.

The risk exposures in this case seem to be from the Alt-Svc MA TTL
extending too long
(ie, long past a typical DNS TTL, so perhaps there should be a cap on the
MA allowed
before re-authenticating with the origin), or if the Alt-Svc is learned
from an Origin
using a MitM CA cert (which we may want to explictly prohibit being used
in combination here as otherwise this could be used to shove everything
through a MitM appliance that can construct certs, unless
that is a desired behavior which I doubt is the case in most places).

          Erik