Re: [Add] Not a good BoF meeting

[Vladimír Čunát <[e-mail]>]

On 7/24/19 10:50 PM, Paul Wouters wrote:
>> On Jul 24, 2019, at 16:22, Vladimír Čunát <[e-mail]> wrote:
>>
>> I'm fairly sure this has been mentioned a few times, but let me repeat
>> it: if you don't (fully) trust the network, how can you bootstrap your
>> trust? (e.g. over insecure DHCP)  You may get some certificate name or
>> key pin, but if you can't first "secure" the channel over which you
>> obtain those, I don't think you get much more real security.
> The preconfigured dnssec root key.

To be clear, I only had DNS *privacy* in mind, as validation of DNSSEC
seems a much easier problem here, not really interesting in ADD.  For
privacy, web CAs or DNSSEC+DANE (yay! more details written by Brian
Dickson) can be used to authenticate the DoT/DoH connections *against a
name*, but for that to be meaningful you need to determine that name in
some secure way.  Otherwise you can end up "securely" sending all your
DNS to https://black.hat.com/doh

BTW, even if we found a technical way how to securely determine that a
certificate/name/server belongs to "current network provider" (without
interacting with the user), it might still be questionable to assume
that the user actually wants to trust this particular network provider. 
For example, Firefox apparently isn't generally comfortable with such an
assumption.  But *if* we had this technical means, I'd personally be
satisfied with a simple dialog asking the user whether the current
network is to be trusted (e.g. "public" vs. "private" button in Windows).

--Vladimir