search

ietf-wg-ohai / draft-ohai-svcb-config

Other
0 stars 4 forks source link

Encrypted DNS isn't sufficient #19

Closed martinthomson closed 2 years ago

martinthomson commented 2 years ago

Attackers on a network can remove SVCB information from cleartext DNS answers [...] Use of encrypted DNS or DNSSEC also can be used as mitigations.

These two things are very different. DNSSEC provides integrity and so - if it is used - is effective. Of course, it is pretty hard to get DNSSEC responses at a stub resolver reliably, but that doesn't mean you can't recommend it.

Encrypted DNS (DoH, DoT, etc...) helps differently. It means that you are no longer exposed to network-based attackers. But that assumes three things if you don't have DNSSEC:

  1. you are able to get (authenticated and) encrypted DNS to the recursive resolver
  2. your recursive resolver doesn't strip SVCB (or the oblivious flag; or the entire mandatory=oblivious RRs) from responses
  3. you are able to get (authenticated and) encrypted DNS between the recursive and the authoritative.

You can drop the last if your recursive does DNSSEC validation for you, which means you are relying on having encrypted DNS and DNSSEC.

tireddy2 commented 2 years ago

Good points. If the client does not support DNSSEC, it has to have a authenticated encrypted connection to the recursive resolver and the resolver has to do DNSSEC validation (signaling to the client that it has done DNSSEC validation using AD bit).

As per https://datatracker.ietf.org/doc/html/rfc5625#section-4.3, resolvers must handle Resource Records (RRs) of unknown type transparently. Resolvers shouldn't be modifying the SVCB RR type.