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

[Petr Špaček <[e-mail]>]

On 28. 05. 20 3:55, Paul Wouters wrote:
> On Wed, 27 May 2020, Petr Špaček wrote:
> 
>> - I don't see any traction for draft-ietf-tls-dnssec-chain-extension. Do you see any evidence it is going to change?
> 
> The draft has been resubmitted for the ISE stream (not TLS WG) as  draft-dukhovni-tls-dnssec-chain
> 
> Stubby already implements it. We do so traction and a lot of interest.
> Viktor wants to add support to openssl.
> 
> But we are unfortunately waiting on the ISE :/

I apologize for being too terse, let me clarify my question:

Is there any indication that TLS libraries are going to implement this? (Unmerged patches do not count!)

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.


>> - 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. 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.


>> 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.

Petr Špaček  @  CZ.NIC