Re: Skipping DNS resolutions with ORIGIN frame

On Tue, Jul 18, 2017 at 6:21 AM, Mark Nottingham <mnot@mnot.net> wrote:

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

This language seems a bit confusing. Usually, MUSTs are intended to impose
requirements on the server, but there's no way for the server to know if
they are meeting client expectations. One could of course invert this to
make it a requirement on clients, but then it's just a tautology that the
client has to enforce client policies.

-Ekr


>
> 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://www.mnot.net/
>
>
>
>

Received on Tuesday, 18 July 2017 15:00:56 UTC