Hi folks,

I wanted to point people to a new draft by Tommy Pauly, David
Schinazi, Chris Wood, and myself that defines a mechanism
for authenticated resolver<->authoritative communication.

At a high level, the design is to use SVCB to indicate that
a given server supports ADo[THQ]. The expectation is that
the SVCB record would be supplied in additional_data along
with the NS records, allowing you to bootstrap to encrypted
transport without incurring additional transport. More details
in the draft, but a few points might be worth fleshing out
here:

- The basic assumption is that the transport to the parent [0]
  is encrypted, thus preventing attackers from substituting
  NS or SVCB [1].

- The draft is agnostic on how the authorative server, and
  is compatible with either TLSA or WebPKI, though there
  are some details to be worked out if we don't mandate
  one or the other.

We missed the draft deadline, so in the meantime the draft can be
found at:

https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html
https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.txt

Comments welcome, etc.

-Ekr

[0] The root may be somewhat tricky here, but there are
some thoughts in the draft.
[1] For reasons laid out in the draft, if this isn't the
case, I'm not sure it's possible to avoid leaking the name
you are resolving, even with DNSSEC.
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to