Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Paul Wouters <[e-mail]>]

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