On Thu, Jul 29, 2021 at 1:19 PM Paul Wouters <[email protected]> wrote: > 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. >
The usual 7258 reasons, namely that forcing an active attack is good. Don't give the user/OS a false sense of privacy if you can't even detect > a MITM. > Can you expand on how someone is getting a false sense of security here? I mean, we're talking about the recursive, right? So generally, the client won't know what's happening at all. > > - (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. > How is this different from seeing who supports TLS but has an invalid cert? Anyway, I'm not going to fight about this piece. -Ekr > Paul >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
