On Thu, 28 May 2020, Petr Špaček wrote:
Is there any indication that TLS libraries are going to implement this?
(Unmerged patches do not count!)
I thought "indication" to implement would be uhm, unmerged patches?
Otherwise, it would be implemented already and you wouldn't need any
more indication?
Having text in form of draft or RFC makes no difference if there are no widely
available implementations... IMHO implementations should be done first before
drafts become RFCs.
Aren't you an implementer? Are you working on this? If not, why not?
- 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:
No. An external progam can update the blob and regularly rewrite it. The
DNS auth server can pick it up using inotify or something.
You are effectively saying the same thing, just in other words.
No I am not. A dnssec-chain can be generated by one machine and
distributed to many auth nameservers. The auth nameservers themselves
do not need to do a single DNS recursive query.
With your proposal auth server operators need to _also_ operate DNS resolver
and tie it together with the auth server. That's very significant change from
how authoritative servers are operated today.
That change is pretty minor compared to to including a whole TLS stack in
a DNS Auth server. Which btw, you could also do with a different program,
to minimize the traditional auth nameserver code.
Compared to hacking all code at nameservers and registries for mangling
and unmangled DNSKEY records, I think that is a very reasonable trade
of.
b) Auth servers nowadays do not even know all their _names_ and do not
care/need to know. How would we solve that?
Whatever part talks TLS, knows the certificate it is using, and can pull
the SAN with FQDN from the certificate.
Ok, hopefully there is not too much of them.
The whole point is that you point many domains to this nameserver, and
the TLS connection to the nameserver isn't configured with a different
cert per domain, or otherwise you might as well not offer any TLS
privacy to begin with. I really don't see the use case for this TLS
channel to have more than one TLS certificate chain to use.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
