Re: Skipping DNS resolutions with ORIGIN frame

On Sun, Jul 16, 2017 at 12:25 PM, Patrick McManus <mcmanus@ducksong.com>
wrote:

> On Sun, Jul 16, 2017 at 12:15 PM, Nick Sullivan <
> nicholas.sullivan@gmail.com> wrote:
>
>> There is merit to both sides. Requiring DNS adds a weak second factor for
>> routing decisions, which is useful in multi-CDN situations, or extra-broad
>> certificates, where you want to prevent a CDN from routing extra traffic
>> via ORIGIN. On the other hand, skipping DNS is a big step forward for both
>> performance and privacy, it basically solves the encrypted SNI issue.
>>
>>
> I think this notion of exchanging the DNS weak second factor for some
> other factor(s) with better perf and privacy properties is promising. Let's
> work with that and thanks especially to Ryan for getting the conversation
> going in that general direction.
>
> First, I'd like to add to the ORIGIN benefit list - beyond perf and
> privacy I believe ORIGIN is operationally superior to the DNS coalescing of
> 7540. By 7540 rules this DNS test will fail any time the zone operator
> can't return a set that matches the resolution that happened when the
> connection was established. For any DNS server that has more addresses to
> choose from than it puts in the RR set, this can be a challenge. I _know_
> that 7540 coalescing fails all of the time because of this (and if it were
> because of traffic management (which it generally is not because I've
> debugged it with the operators) then ORIGIN provides a finer control for
> that anyhow)
>
> ISTM the primary concern is that the DNS provision amplifies the power of
> the certificate (depending on how much value you think DNS has a second
> factor that could be by a factor of 1.0001 to MAXINT - we probably don't
> need to come to consensus on it) in the case of misissuance or compromise.
>
> So curating from the ideas floating around I would suggest that a origin
> client MUST skip the DNS check if
> a] the connection certificate used to validate the origin comes with SCT.
> This is to mitigate against mis-issuance. Given that we can expect all
> public certifcates published a year from now to deal with CT, this seems
> pretty easy operationally to me.
>

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?


>
> b] the connection certificate used to validate the origin passes a
> revocation check. This is to mitigate against compromise. In the case OCSP
> was not stapled the client could choose between ocsp and just doing the dns
> (or ignoring the origin extension). So there
> is motivation to staple.
>

> I don't think we want to make a certificate extension that says "opt-in to
> skip DNS" (it is tatamount in some ways to selecting for people who have
> something to hide that they're willing to put in the work to deal with
> certificate changes - not a good privacy feature)..
>
> -Patrick
>
>
>