Re: [Add] Not a good BoF meeting

[Brian Dickson <[e-mail]>]

On Wed, Jul 24, 2019 at 4:50 PM Paul Wouters <[e-mail]> wrote:

>
>
> Sent from mobile device
>
> > 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.
>

And just to complete the picture for those less familiar with DNSSEC and
DANE:

   - the root key gives you validation of signatures in the root zone,
   including for the chained trust links across DNSSEC-secure delegations (to
   TLDs)
   - The DNSSEC-signed TLDs (with KSK and ZSK signed by KSK, whose finger
   print is the chained trust record "DS"), give you similar chained trust
   links downward...
   - Eventually, you end up inside a DNSSEC-signed zone, which contains
   - signed A/AAAA records (thus you have cryptographic proof of the values
      for the IPv4 and IPv6 addresses), plus
      - signed TLSA records which provide cryptographic proof of values for
      either the CA or the end entity cert (EE),
         - as either full certificate or as fingerprint,
      - Thus, completing the secure bootstrap to a TLS certificate  (or
   fingerprint) plus IPv4/IPv6 address(es)

The above supports some forms of aliasing along the way (CNAME and DNAME),
as well, which are also DNSSEC-compatible (e.g. signed CNAME or DNAME
records, if they point to DNSSEC-signed targets)

You can see why the DNS folks are proponents of DNSSEC and DANE, in this
discussion.

Without these, secure bootstrap is a very difficult problem.

With DNSSEC and DANE, the problem is already solved, modulo deployment of
DNSSEC by zone owners, and modulo implementation of native DANE in browsers.

Brian