Hi Shumon, On Tue, 2020-06-09 at 12:37 -0400, Shumon Huque wrote: > I think TLSA in the child zone could be made to work though, so I think it's > still worth thinking about some more. Here's my suggestion: > > Place the TLSA record at the zone name, i.e. at the apex of the child zone, > rather > than at the NS server names: _853._tcp.example.com/IN/TLSA. > > That solves the name authentication problem because the nameserver names > aren't authenticated in the referral, but the zone name is authenticated via > the > signed DS RRset.
What SNI do you then use when connecting to a name server? > The initial bootstrapping problem can be addressed by using the TLS > DNSSEC chain extension, which can deliver the zone's TLSA > RRset on first contact, in-band in the TLS handshake. You mention the > possibility of "stuffing the TLSA chain in TLS" - I wanted to make sure > you knew the design work for this mechanism is already done: > > https://tools.ietf.org/html/draft-dukhovni-tls-dnssec-chain-01 I know that that is exactly what Robin referred to :) > Using the TLSA RR means that we can now support the full semantics > of TLSA: EE cert, auth, local TA issued cert, or PKIX/WebPKI constraints. No, because you don't know the name server names with certainty, so you're still limited to pinning the key, the last cert in the chain, or using a private CA. WebPKI most certainly is out, because ns.attacker.org could also get a cert from the same public CA. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
