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

[Tony Finch <[e-mail]>]

Thanks for reading and providing feedback!

Peter van Dijk <[e-mail]> wrote:

> On Wed, 2020-11-11 at 19:07 +0000, Tony Finch wrote:
> >
> >   * Encryption would apply to the server as a whole, whereas the
> >     working group consensus is that it should be possible for
> >     different zones on the same server to use encrypted and
> >     unencrypted transports.
>
> (plus, in another email, Tony wrote: "A nice thing about TLSA records
> is they also tell the client what name to look for in the server's
> cert.")
>
> This looks like a mistake to me, or at least, a choice that would have
> to be made very deliberately.

My point above mostly relates to section 5.1 points 7 and 9 of
https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02

I agree that this is very arguable but I think it's hard to avoid.

> Today, the name through which I reach an NS does not matter - it is not
> part of the protocol exchange like the HTTP Host header is. This
> simplifies a lot of things, and allows some leeway for mismatches in
> names between parents, childs, etc., as long as they reach the same IP.

Right. I need to write more about this issue of nameserver aliases,
something like the text below. (Er but I need to avoid the term "alias"
because that's tied up with CNAMEs which are not allowed for
nameservers...)

> It also seems that any 'split' between which zones on a certain IP
> support encryption and which zones do not, would make any opportunistic
> proposal obsolete immediately.

I'm not sure what you mean here because "opportunistic" has multiple
meanings, and they have different implications for how a client might
authenticate a server.


... and now the text below ...


## TLS certificate authentication

The DNS does not currently depend on the name that appears in an NS
target, provided it resolves to the IP address(es) of the intended server.
In particular the NS name does not have to be the server operator's
preferred name. Zone operators sometimes use different nameserver names
because they prefer to avoid glueless delegations, for example.

The widespread use of unofficial nameserver names means it is impossible
for a nameserver to present a certificate that always matches the
`subjectAltName` `dNSName` [RFC 6125] expected by the client. There are a
number of ways to avoid this problem:

  * Authenticate the server by `subjectAltName` `iPAddress`. Unfortunately
    IP address certificates are hard to obtain (though this is likely to
    become easier after [RFC 8738] is deployed). This is only an advantage
    when there is no signal associated with the nameserver's name (such as
    TLSA records) indicating support for encrypted transports, because if
    there is such a signal the client knows what name to expect in the
    certificate.

  * Use the syntax of the name, such as a `dot--` prefix, to indicate that
    the name will match the certificate. This has the disadvantage of
    requiring all delegations to be updated.

  * Ignore certificate name mismatches, and authenticate just the public
    key. This raises the question of how the client can find out the right
    public key: if it can find out the right key why can't it also
    find out the right name? It has the disadvantage that public key
    pinning has a poor operational track record.

  * Use the presence of a DNS record associated with the nameserver name
    to indicate that the server's certificate will match the name. For
    example, TLSA records alongside the nameserver's address records;
    other possible kinds of records for doing this job are discussed in
    the following subsections.


## Nameservers with multiple names

This proposal involves four kinds of name that a nameserver operator needs
to consider:

  * A nameserver's official name, which is used in the vast majority of NS
    records pointing at this server. The presence or absence of a TLSA
    record associated with this name controls whether transport encryption
    is used for the owners of these NS records.

  * A `dot--` tagged name, which can provide better privacy when the NS
    target name is below its own zone cut, and is not necessary in other
    cases.

  * Unofficial names that differ from the server operator's preferred
    name. Zones using unoffical nameserver names are likely to have
    problems using an encrypted transport, for example because of the need
    to keep TLSA records in sync. The server operator can (in principle)
    determine the extent of this problem by auditing all the server's
    zones' apex and delegation NS records.

  * Alternative names that advertise different encrypted transports than
    the official name. A nameserver operator can use different names for
    the same nameserver to support encryption for a subset of zones. This
    might be useful for testing or phased rollout.

A nameserver's support for encrypted transports is a server-wide option,
analogous to the IP addresses and ports that the server listens on.
Whether a zone supports encryption or not is a matter of which records
appear in the DNS, not how the server is configured. A nameserver should
serve the same zones over encrypted transports that it serves over the
corresponding UDP and TCP transports.

[This slightly weird phrasing is to avoid ruling out features like views
or split horizons.]


Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Whitby to Gibraltar Point: Southwest 5 or 6, increasing 7 at times. Slight,
occasionally moderate. Rain at first. Moderate or good.