Re: Skipping DNS resolutions with ORIGIN frame

On Tue, Jul 18, 2017 at 2:47 PM, Ryan Hamilton <rch@google.com> wrote:

> On Tue, Jul 18, 2017 at 9:41 AM, Mike Bishop <Michael.Bishop@microsoft.com
> > wrote:
>
>> I'd either say something like "Clients opting not to check DNS SHOULD
>> employ some alternative means to increase confidence that the certificate
>> is legitimate, such as Certificate Transparency or revocation checks," or
>> just stop after the first sentence.  If it's a MAY, then it's up to the
>> clients under what specific conditions they employ it.  The main reason, in
>> my mind, for adding the second sentence is to inform less-security-aware
>> developers that they shouldn't just toss DNS out the window without having
>> something else in hand.
>>
>
> This seems like the right direction to me.​
>

To me as well.  Based on the discussion above, CT and revocation checks are
addressing different threats, so "Certificate Transparency AND some
revocation checking mechanism" may not be appropriate.  "Additional" is
also better than "alternative" since this is above and beyond other
checking normally done.

We may also want to explicitly suggest (in Security Considerations?) that
clients SHOULD NOT trust certs side-loaded outside of the trust chain for
coalescing.  Otherwise this makes it much easier for MitM appliances to
slurp up traffic without even needing to be on-path.



What I means is that if I connection to www.example.org which presents an *.
> example.org certificate, I need some second piece of information before
> using it for mail.example.com. In the alt-svc case, if an earlier
> connection to mail.example.org advertised alt-svc for www.example.org,
> then I would be comfortable coalescing the connection​ and would not need
> to do any resolution of mail.example.org.
>

While this does still require going back to mail.example.com at least once
(so doesn't help for the privacy scenario), it may be worth considering
this. In particular, if multiple origins all Alt-Svc to the same server
name (and perhaps also include a "coalesce=1" attribute to the Alt-Svc?)
then this may also be a good enough indication of positive control by the
origins when combined with normal cert validation?


In a side-discussion in Chicago, there was a conversation around "signed
Alt-Svc attestations" that could be distributed out-of-band from requests
(e.g., signed by a cert covering the origin with a special cert extension
and perhaps also logged in a CT log) and combining those with server-pushed
certs to enable coalescing and skipping DNS (for privacy and performance
purposes).  This seems to have similar security properties and threat
vectors to some of what we're discussing.  Factoring out the security
analysis and mitigations to generalize across these might be useful?


Mark Nottingham wrote:
>
> Yeah. Like I said, we don't usually specify this sort of detail in
> HTTP-land, hence the vagueness. We can change that, of course.


The challenge is that attackers won't be constrained by layer boundaries,
and the practical attacks here likely come from creatively exploiting
weaknesses spanning a few layers, especially if we are removing inter-layer
constraints (eg, DNS following that used to be present).  As such, our
specific mitigations or recommendations may also need to cross layers more
than usual.

      Erik