On 27. 05. 20 3:27, 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. DoT
> authoritatives would need to keep both the old and new certificates on hand
> during the transition, and DoT recursives would need some way to signal in
> the ClientHello which one they are expecting. This is pretty far from how
> TLS normally works.
The proposed mechanism works the other way around:
Zone can have multiple DS records at a time, thus exposing multiple hashes to
resolvers. Rresolver then checks if any of the hashes in DS matches, so the
auth side can be use any cert without prior communication with resolver.
>
> 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 can see three problems, not sure which one is worse:
- I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you
see any evidence it is going to change?
- If I'm not mistaken authoritative servers implementing
draft-ietf-tls-dnssec-chain-extension would need to add DNS resolver to refresh
chain of records leading to TLSA records under their name:
a) Having resolver on auth side is major paradigm change in deployment of auth
servers and I'm not convinved auth operators would be happy with it as it adds
additional fragility.
b) Auth servers nowadays do not even know all their _names_ and do not
care/need to know. How would we solve that?
Petr Špaček @ CZ.NIC
>
> On Tue, May 26, 2020 at 5:13 PM Peter van Dijk <[email protected]
> <mailto:[email protected]>> wrote:
>
> On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> > I thought using keytag 0, which cannot happen normally, would allow
> > you to leave algorithm and other values more real.
>
> This comment made me curious. Why would that be true? So I generated
> 524726 keys equally split between algorithms 8, 13, and 15.
>
> The result: 2 algo 13 keys with tag 0, 7 algo 15 keys with tag 0. I've
> pasted them at
> https://gist.github.com/Habbie/feb0bf288ea1137bee5a2c3d8913ba7f (happy
> to provide the related private keys if anybody cares).
>
> None for RSA, though, which I bet was predicted in the work behind
>
> https://indico.dns-oarc.net/event/22/contributions/315/attachments/316/555/Quest_for_the_missing_keytags.pdf
> and
>
> https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
