Re: [dns-privacy] re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Peter van Dijk <[e-mail]>]

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/