Re: [dns-privacy] how can we ADoT?

[Tony Finch <[e-mail]>]

Peter van Dijk <[e-mail]> 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  <[e-mail]>  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.