On Tue, 2020-11-17 at 01:21 +0000, Tony Finch wrote: > Thanks for reading and providing feedback! > > Peter van Dijk <[email protected]> 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 strongly believe point 9 should be removed, for reasons articulated in my previous email briefly quoted above :) > 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. Opportunistic is, perhaps deliberately, vaguely defined. 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'. > ... and now the text below ... > > > ## TLS certificate authentication > > * 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. 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). > * 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. As above. (Not saying that it is the only way, but 'a name server has no name' has a lot of convenient properties.) > * 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. 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. > * 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. Makes sense, that's what puts the NS owner in control of transport, instead of (or together with) the zone owner. > * 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. This is neat. > A nameserver should > serve the same zones over encrypted transports that it serves over the > corresponding UDP and TCP transports. Yes! > [This slightly weird phrasing is to avoid ruling out features like views > or split horizons.] Cleverly boxed. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
