To recap what I was saying on the list, here's my proposal: - 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.
- 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. [1] 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. - (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. This would allow for: - Unauthenticated to work and be discovered. - An easy upgrade to authenticated after initial contact (a la HSTS etc.) - A path to fully authenticated from initial contact if we ever figure out the parent signaling, because you just need to propagate the contents of SVCB (or some subset). -Ekr [0] As PaulH says, this won't work with DoH because of ambiguity about the path portion. [1] This signal should only be accepted over an authenticated connection, a la HSTS.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
