On Tue, Jun 9, 2020 at 1:26 PM Peter van Dijk <[email protected]> wrote:
> 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? > Well, the client could just use the zone name as the SNI, no? You can assign certificates with the same name but different keys to each of the nameservers. Or if the administrator is willing to do shared certificates/keys, that would work too. 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 :) > Ok, I just wanted to make sure. > > 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. > Here again, if the protocol expects only the zone name, we could adapt. For example, I could deploy a DANE-TA CA, and use that to issue individual certs for the zone name. So I don't think we are actually limited to just pinning the EE cert's keys (even if that may turn out to be the most popular deployment choice). Shumon.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
