On Wed, 10 Jun 2020, Brian Dickson wrote:
The principle is easy. What's hard is the Provisioning Crudware(TM)
that will have to be updated to handle TLSA glue. You might see this
as a dealbreaker, with the alternative being to abuse DS or some other
record that we hope the Crudware already handles.
No, this isn't TLSA glue... this is TLSA below the delegation point for the
authority server's zone (which is serving the NS name and has the TLSA
records for all those NS names).
Except that it is in effect glue, because the parent send a copy of the
TLSA so the client knows what certificate to look for. The TLSA is also a
signal that the child supports DoT.
The presumption I make is that there is nothing to add for provisioning
this...
OK, plan A 1/2 is there's no TLSA glue, the client connects to whatever IP
the NS purports to be, without trying to validate the certificate at the
time, then fetches the signed NS and A/AAAA and TLSA and sees if it
matches what it's seen.
The problem with that is that there is now no signal on the parent side
that the client should look for DoT in the child. It might also leak
more, haven't thought too hard about that.
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
