Re: Skipping DNS resolutions with ORIGIN frame

On Tue, Jul 18, 2017 at 7:29 PM, Watson Ladd <> wrote:

> On Tue, Jul 18, 2017 at 2:23 PM, Mike Bishop <
> > wrote:
>> Unless the 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 (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 can change
> for various reasons.
> We can't have advertise every single customer as an
> Alt-Svc.
Strawperson:  if every one of a CDN's sites (including
did an:

                  Alt-Svc: h2=""; 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
saying that connections to can safely coalesce as long as
there is cert coverage.
ie, if the cert presented when connecting to and sending
SNI="" covers "", 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
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).


Received on Wednesday, 19 July 2017 01:27:05 UTC