Thanks for the explanations. Having multiple TLS-DS records during TLS key rolls does seem like a pretty good solution.
There are still some potential operational rough edges here. For example, an "emergency" certificate replacement (e.g. in event of compromise) is difficult, because the old fingerprint set might be cached all over the internet. Cautious authoritative operators might have to set low TTLs, resulting in slower lookups and increased load on the parent zones. In my view, the most important link for ADoT is to the TLD, because the TLD+1 is typically the most sensitive label. In this solution, TLS key agility seems likely to be particularly difficult for TLD operators, assuming that updating the root zone is relatively slow. I agree that the TLS DNSSEC chain extension isn't substantially deployed today, but I don't think that should stop us from using it if it would help. This use case is important enough to drive deployment. Using this extension would indeed require the authoritative server to provide TLSA records for its own name. I don't think it actually has to "resolve its own name", because it can choose a name that is in-bailiwick. Servers can choose an in-bailiwick authentication name even if existing NS records have an out-of-bailiwick name. If an authoritative server has multiple names, it would presumably identify the right one from the TLS-SNI. On Wed, May 27, 2020 at 4:28 AM Peter van Dijk <[email protected]> wrote: > Hello Ben, > > On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote: > > I like the idea of signalling DoT support in the DS record, but I worry a > bit about putting the SPKI fingerprint in the DS as well. Having to update > the parent zone whenever the TLSA key needs to be rotated seems cumbersome > and fragile, especially if the nameserver is operated by a third party. > > > I agree, it's the weakest link in the proposition. > > DoT authoritatives would need to keep both the old and new certificates on > hand during the transition > > > keys, not certificates > > , and DoT recursives would need some way to signal in the ClientHello > which one they are expecting. > > > I don't follow - if the DS set has both the old and new keys, the DoT > recursive will accept either. I ki > > This is pretty far from how TLS normally works. > > > Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm > missing something. > > I wonder if you considered using draft-ietf-tls-dnssec-chain-extension > instead? That would provide the same security and performance, using less > volatile information in the parent. Specifically, I think that the DS > record would have to convey one bit ("DoT enabled") plus the name of the > nameserver (which should probably match the NS record). That seems > preferable to me. > > > I considered putting names in DS records; I also considered > chain-extension; but I failed to consider them together! With NS names > 'verified' by DS, that looks like something that would also be secure. I > agree with the problems Petr spotted - I'm aware of roughly zero > implementations of dnssec-chain in clients or servers. > > That seems preferable to me. > > > For me, with 10 domains on two name servers, not having the complexity of > chain-extension is preferable. For others, with a million domains, > obviously our draft does not scale. I've been assuming we'd end up with two > or three separate signals, each fit for purpose for a certain scale. Your > proposal seems like a viable candidate to be one of those to me. > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
