On Thu, 29 Jul 2021, Eric Rescorla wrote:
- Recursives can attempt to connect to any authoritative by probing with DoT/DoQ [0]. In this case, they should cleanly fall back to Do53 on connect failure and not validate the credential (whether WebPKI or DANE) This allows authoritatives to just turn on TLS without risk.
I agree. And importantly, they can turn on _credentialed_ TLS without risk. If you would allow to continue "unauthenticated", then the DNS operator still has a future hard decision to make when to insist on authenticated. They again have to make a risky decision. The fact that "unauthenticated" works as standalone or fallback is no guarantee whatsoever that adding credentials to that setup won't cause complete failure.
- The SVCB record is used to signal that the authoritative expects to do TLS and indicates the type of credential (WebPKI, DANE, etc.) that the authoritative intends to present. The recursive should insist on TLS in this case and hard fail if it cannot negotiate.
Yes, I tried to do exactly this with TLSA records <grumbles about history> And this is what TLSA for SMTP actually does.
If there is an overlap between the credentials the recursive supports and the ones the authoritative advertises, then the recursive should validate the credential and fail if it cannot. If there is no overlap, it should not validate the credential.
If there is no overlap, why even try the transport? Just do port 53. Don't give the user/OS a false sense of privacy if you can't even detect a MITM.
- (Optional) We should invent some way for the server to say in SVCB that it doesn't have any valid credential (e.g., a reserved credential type). This would be a signal you wanted unauthenticated.
Now you are advertising which DNS servers can easilly be MITMed. An attacker can live query the DNS to see if it should commence attacking. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
