Peter van Dijk <[email protected]> wrote: > > What I think I mean to say there is 'if an auth NS responds on port 853, > it had better offer me all the data it also has to offer on 53'.
Yes, I think that makes the most sense. > > * Authenticate the server by `subjectAltName` `iPAddress`. [snip] > > For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending > a server name at all (which matches what I said earlier - name servers > have IPs, not really names). Do you mean not sending in TLS SNI? Yes, that would make sense if we're not doing name-based auth. (I have not really thought about SNI in this context; might be useful for operators who like to use glueful delegations with alternate nameserver names per zone, though I expect that will end up causing sadness if they don't control all the zones.) Even with RFC 8738 acme ip, there's the wrinkle that you can't use acme dns-01 challenges to get the cert - ironic :-) > > * Ignore certificate name mismatches, and authenticate just the public > > key. [snip] > > As above. (Not saying that it is the only way, but 'a name server has > no name' has a lot of convenient properties.) There's another downside to this case: with IP-based or name-based auth, you can put the CA's public key in the TLSA rather than the server key, so there's less rollover churn, but that doesn't make sense for key-based auth. > > * Use the presence of a DNS record associated with the nameserver name > > to indicate that the server's certificate will match the name. > > First thought: yes. Second thought: what if the owner of the 'vanity > name' 'aliased' to the NS just copies the TLSAs? At sufficient > deployment, the failure mode is immediate and clear, of course. That should lead to a certificate name mismatch. If we aren't doing name-based auth then there won't be an immediate failure; instead it's likely to go wrong when the server operator rolls their keys or switches CA, and that delayed failure will be HORRIBLE to debug. I think there are significant (albeit woolly) advantages to staying as close as possible to normal webPKI for DoT: much lower congnitive load for operators who can reuse their https knowledge; deveopers don't have to write code that's too weirdly different from https; very straightforward parallel deployment for DoT, DoH, DoQ (if we ever want to support more transports). On the other hand you are right that IP address auth is much closer to the way the DNS works now. I think the other most plausible design for ADoT is in-band signalling with a strict transport security option and ip-based auth. (As Ekr said) https://mailarchive.ietf.org/arch/msg/dns-privacy/Qhn62UWBclwNXjlMaUNoT6M9sMU/ Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Thames, Dover: Southwest veering northwest later, 6 to gale 8, perhaps severe gale 9 later, decreasing 4 to 6 later. Moderate or rough. Showers. Moderate or good. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
