On 28. 05. 20 18:08, Paul Wouters wrote: > 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?
Hmm, apparently I cannot convey idea from my head to text form, sorry! Let me clarify: Unmerged patches mean nothing _unless_ upstream does say it is interested in working on them and eventually merging them. I or you can submit whatever patches we want to OpenSSL or GnuTLS and it means nothing until maintainers give us their opinion on them. >> 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? The question above is pointless without library support which is what I was attempting to find out above. Nonetheless I'm not convinved this is a good approach, see below. > >>>> - 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. That's understood. > >> 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. I disagree. Adding TLS server or proxy means adding self-contained code which does not depend on communication with anything else (barring OCSP stapling etc.). dnssec-chain-extension on auth adds new depedency on resolution chain. No matter how it is implemented that's a pretty big change from how auth servers are operated today: - Nowadays auth servers depend only on their master server/replication topology. - tls-dnssec-chain-extension would add either DNS resolver /or/ another replication topology for dnssec-chain-extension /or/ extension to zone transfer mechanism (so it can use the same topology as zone data). None of this seems like (operationally) straightforward change. Keep in mind that a smallish ccTLD like CZ has hundreds of machines in different corners of planet so adding yet-another-replication-topology for DNS responses just for TLSA is going to be major PITA to operate, and so does operating hundreds on resolver instances on each auth server. > > 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. That's a good point! -- Petr Špaček @ CZ.NIC _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
