RE: Skipping DNS resolutions with ORIGIN frame

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.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Tuesday, July 18, 2017 6:22 AM
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Emily Stark <estark@google.com>; Nick Sullivan <nicholas.sullivan@gmail.com>; Ilari Liusvaara <ilariliusvaara@welho.com>; Erik Nygren <erik@nygren.org>; Piotr Sikora <piotrsikora@google.com>; Ryan Hamilton <rch@google.com>; ietf-http-wg@w3.org
Subject: Re: Skipping DNS resolutions with ORIGIN frame

Editor hat on.

The spec currently contains:

"""
* Clients MUST NOT consult DNS to establish the connection's authority for new requests. The TLS
  certificate MUST still be used to do so, as described in {{!RFC7540}} Section 9.1.1.
"""

It sounds like we're moving towards something more like this:

"""
Clients MAY ignore the requirement in {{RFC7540}} to check DNS when establishing a connection's authority for new requests, but the TLS certificate covering any additional origins MUST still be used to do so, as described in {{!RFC7540}} Section 9.1.1. Additionally, such certificates MUST adhere to client policy regarding revocation and certificate transparency {{trans ref}}.
"""

Thoughts / suggestions / modifications? 

One thing that's been discussed is requiring either a) one of a selection of techniques as a "second factor", b) a specific one (e.g., CT). I *think* the details of that is the big question remaining.

I'm not including that in the version above yet because historically, we've been shy of specifying client policies in HTTP specs. Discuss.

(There's a fair amount of other editorial work this will entail to get it to integrate well into the text, but I think that's the meat of it)


> On 18 Jul 2017, at 2:37 pm, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> 
> 
> On Mon, Jul 17, 2017 at 10:40 AM, Emily Stark <estark@google.com> wrote:
> Do you mean literally comes with a single SCT? Or complies with the client's CT policy (which might require multiple SCTs)? Is it reasonable to assume that all clients implementing ORIGIN will also implement CT?
> 
> Thanks Emily.
> 
> I think you're right that we mean SCT policy. I also wonder if we shouldn't say something like "if the origin doesn't meet the client's  ct/revocation requirements it[*] MUST be ignored" rather than having the client do the DNS lookup.. it seems to me like that could leak some domain names for little value.
> 
> [*] it here means the origin in the origin frame... not blacklisting that origin from the whole client :)
> 
> 
> 

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cc5df925db14a405978a308d4cde07d56%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636359811454583008&sdata=tWKd9qRMXhw4U2T0AuHonrlDw6mIhLqVQDqREeXTTqY%3D&reserved=0

Received on Tuesday, 18 July 2017 16:41:55 UTC