Re: Skipping DNS resolutions with ORIGIN frame

> On 19 Jul 2017, at 8:31 am, Erik Nygren <erik@nygren.org> wrote:
> 
> 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.

...

> 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.

I was trying to say that we don't want to MUST a particular solution (e.g., a CT or revocation check), since we don't go to that level of detail currently. You seem to agree with this approach above, or do I read that wrong?

Regards,

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 25 July 2017 04:57:33 UTC