Re: [dns-privacy] Amortization techniques for less popular name server names
On Mon, Nov 16, 2020 at 5:28 PM Tony Finch wrote: > Brian Dickson wrote: > > > Attempting to do XFR for many name servers which are infrequently used > > would have scalability issues from any resolver, if the server names are > > in a large number of zones. One approach to reducing this issue is > > aggregating server names inside many fewer zones. Doing this aggregation > > creates trust issues, however. > > Summarizing brutally :-) this sounds a bit like a combination between DLV > and hyperlocal root zones? > Yes, exactly. (When I was writing it up, that thought even crossed my mind.) The irony is not lost on me, either. :-) Brian ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Amortization techniques for less popular name server names
Brian Dickson wrote: > Attempting to do XFR for many name servers which are infrequently used > would have scalability issues from any resolver, if the server names are > in a large number of zones. One approach to reducing this issue is > aggregating server names inside many fewer zones. Doing this aggregation > creates trust issues, however. Summarizing brutally :-) this sounds a bit like a combination between DLV and hyperlocal root zones? Tony. -- f.anthony.n.finchhttp://dotat.at/ Thames, Dover: Southwest 5 to 7. Moderate or rough, occasionally slight later. Rain or drizzle at first. Moderate or good, occasionally poor. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
Thanks for reading and providing feedback! Peter van Dijk wrote: > On Wed, 2020-11-11 at 19:07 +, 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
Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
On Mon, 2020-11-16 at 10:22 -0800, Brian Dickson wrote: > > > That's a moot point. > > > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC > > > 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be > > > based on the > > >DNSSEC validation state (as defined in [RFC4033]). > > > > Which buys you very little if the name you are looking up is from an > > unauthenticated source - like NS names in delegations. > > > > Ah, okay, now I understand. > > Yes, this is a huge gap in the fundamentals for any privacy architecture > (ADoT), which is rooted in the unsigned nature of NS records regardless of > the security state of a delegation (DNSSEC or not). Indeed. That's why we designed DOTPIN (whose shortcomings pretty much come from not being NS-centric!) to not rely on those names. > This pretty much impacts any solution that relies on either the names or IP > addresses of authoritative servers (the latter served as glue from the TLD). > An on-path active adversary (between recursive and TLD authoritative server) > would be able to modify these unsigned values. Exactly. A TLSA-authenticated ns1.evil.org does you no good. > Without any way to obtain them with some degree of protection (transport or > data), there is no path to connecting to the correct server initially over > TLS. We could twist this into saying that we can solve the problem by also doing DoT on the root and the TLDs! (But you also mention that below.) > If the domain in question (the delegated domain, not the nameserver > namespace) is DNSSEC signed, it is possible to detect a discrepancy between > the delegation and apex NS records, assuming DNSSEC responses are not blocked > or tampered with. Yes - but by then you've already leaked yourdirtysecrets.com to ns1.evil.org! > If the domain in question is not DNSSEC signed, there is no defense against > such an attacker, if the query to the TLD is not protected by transport or > data security. > However, even in the signed zone case, confirming the apex NS records does > require a query to the authoritative server to verify things, > If the IP address used operates on port 853, there is no guarantee the server > responding is the actual authoritative server rather than an attacker's > server, since the name/IP could have been tampered with initially. Yes (examples given above). > This leads to a few possible conclusions: > * With no changes to the DNSSEC management of TLDs (protocol and > implementations), and with no availability of ADoT to TLD servers, an on-path > active adversary : > * * Can defeat any attempt at privacy (ADoT) for unsigned zones > * * Can at most DOS any privacy mechanism for signed zones Yes and yes. > * The following techniques can alter the prerequisite conditions, each of > which has deployment/operation concerns: > * * Changes to DNSSEC signing of (at minimum TLD) delegation data (NS records > and glue A/ records) I mentioned 'hash of NSSET into DS' in a dprive thread earlier. https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/ does something like this (including glue, which we don't need for our problem). > * * * Many large hurdles to overcome, including standardization, > implementation, and deployment > * * * May not be offered by all (or even any) TLDs I believe DOTPIN (again, with all its shortcomings) has very few hurdles in this area. > * * Availability of ADoT at TLD servers > * * * Protects traffic via TLS > * * * May not be offered by all (or even any) TLDs It's DNSSEC all over again. > * * Eliminating the on-path possibility, by obtaining the TLD zone via > AXFR/IXFR > * * * Protecting the TLD zone transfer is possible by either ZONEMD > signature, or by doing AXFR over TLS > * * * May not be offered by all (or even any) TLDs Last time I checked, TLD operators where not very eager to drop whole zone dumps on the world. Also, some zones are simply too large for this. Ignoring those issues, yes, ZONEMD and/or XoT would solve the on- path problem. > > > So, downgrade-resistant, period. > > > > No. > > I stand corrected. > Downgrade resistant only if the delegation information is protected (NS names > in particular). Indeed, and the privacy properties then still depend on what the NS names (and their IPs) tell you. (Some of that goes for DOTPIN as well, of course). > Protecting the delegation NS records against an on-path adversary (between > resolver and TLD) does not have any nice solutions. I like 'hash of NSSET [in DS]'. Now perhaps you see why I offered these possibly-useful puzzle pieces earlier: * https://tools.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt * https://tools.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt Both of these make room for non-hashing variants of 'authenticate data that is unsigned today'. :-) (If you'd like to have more puzzle pieces,
Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
On Mon, Nov 16, 2020 at 2:02 AM Peter van Dijk wrote: > On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote: > > > > > > Using TLSA records at _853._tcp. in a signed zone provides > an unambiguous signal to use optionally TLSA, in a downgrade-resistant > manner. > > > > > > Not downgrade-resistant, until NS names in delegations become signed. > > > > That's a moot point. > > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC > 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be > based on the > >DNSSEC validation state (as defined in [RFC4033]). > > Which buys you very little if the name you are looking up is from an > unauthenticated source - like NS names in delegations. > > Ah, okay, now I understand. Yes, this is a huge gap in the fundamentals for any privacy architecture (ADoT), which is rooted in the unsigned nature of NS records regardless of the security state of a delegation (DNSSEC or not). This pretty much impacts any solution that relies on either the names or IP addresses of authoritative servers (the latter served as glue from the TLD). An on-path active adversary (between recursive and TLD authoritative server) would be able to modify these unsigned values. Without any way to obtain them with some degree of protection (transport or data), there is no path to connecting to the correct server initially over TLS. If the domain in question (the delegated domain, not the nameserver namespace) is DNSSEC signed, it is possible to detect a discrepancy between the delegation and apex NS records, assuming DNSSEC responses are not blocked or tampered with. If the domain in question is not DNSSEC signed, there is no defense against such an attacker, if the query to the TLD is not protected by transport or data security. However, even in the signed zone case, confirming the apex NS records does require a query to the authoritative server to verify things, If the IP address used operates on port 853, there is no guarantee the server responding is the actual authoritative server rather than an attacker's server, since the name/IP could have been tampered with initially. This leads to a few possible conclusions: - With no changes to the DNSSEC management of TLDs (protocol and implementations), and with no availability of ADoT to TLD servers, an on-path active adversary : - Can defeat any attempt at privacy (ADoT) for unsigned zones - Can at most DOS any privacy mechanism for signed zones - The following techniques can alter the prerequisite conditions, each of which has deployment/operation concerns: - Changes to DNSSEC signing of (at minimum TLD) delegation data (NS records and glue A/ records) - Many large hurdles to overcome, including standardization, implementation, and deployment - May not be offered by all (or even any) TLDs - Availability of ADoT at TLD servers - Protects traffic via TLS - May not be offered by all (or even any) TLDs - Eliminating the on-path possibility, by obtaining the TLD zone via AXFR/IXFR - Protecting the TLD zone transfer is possible by either ZONEMD signature, or by doing AXFR over TLS - May not be offered by all (or even any) TLDs > > So, downgrade-resistant, period. > > No. > I stand corrected. Downgrade resistant only if the delegation information is protected (NS names in particular). Protecting the delegation NS records against an on-path adversary (between resolver and TLD) does not have any nice solutions. Brian ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote: > > > > Using TLSA records at _853._tcp. in a signed zone provides an > > > unambiguous signal to use optionally TLSA, in a downgrade-resistant > > > manner. > > > > Not downgrade-resistant, until NS names in delegations become signed. > > That's a moot point. > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC 6698 > section 4.1 (Determining whether a TLSA RRSet can be used MUST be based on the >DNSSEC validation state (as defined in [RFC4033]). Which buys you very little if the name you are looking up is from an unauthenticated source - like NS names in delegations. > So, downgrade-resistant, period. No. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
