Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
On Wed, Nov 18, 2020 at 6:29 PM Shumon Huque wrote: > On Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk < > peter.van.d...@powerdns.com> wrote: > >> On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote: >> [...] >> > If (big if) we think it's worth upgrading the DNS delegation model (and >> > EPP, and all the registries and registrars, and all the IPAM databases >> and >> > user interfaces, and documentation and textbooks), can we also tackle >> the >> > scalability problem? By "scalability" I mean the need for a hosting >> > provider to update N delegations when a server cert changes. And >> there >> > are decades old problems keeping delegation NS and glue and DS records >> > correct. (A large chunk of the "it's always DNS" meme comes from how >> hard >> > it is to understand delegations and update them correctly.) This whole >> > area is a massive pain in the arse sorely in need of universal >> automation. >> >> +100. I've referred to this in other threads - if CloudFlare had gotten >> anywhere with their attempts to solve the operator / registrant / >> registrar / registry disconnect problem, all of this would be so much >> easier. >> > > At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a > challenge to DNS Operators to organize and become an officially > recognized constituency within ICANN. If that were to happen, then it might > be able to address and solve some of these issues over time, given > adequate engagement. > > > Any serious attempt at improving delegations needs to deal convincingly >> > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so >> > appallingly bad. >> >> Yes, or in the broader sense, my previous paragraph. >> > > At the same workshop, Jim Galvin spoke about some of the structural reasons > why it's challenging for the contracted gTLDs to make progress on > supporting > these (and also likely why there has only been adoption at a small number > of > ccTLDs, who are non-contracted parties). This was in relation to CDS and > CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to > date. > At the same Workshop, in our presentation I mentioned that we (GoDaddy) are intent on providing CDS/CDNSKEY support. This is to work around the logjam which is the RRR system and its structural limitations. Specifically, we will support our Registrar customers who are not DNS customers, by polling them for CDS/CDNSKEY records no matter who hosts their DNS. We will then submit those via EPP (which we can do only because we are their Registrar). Nothing about this is rocket science, nor is it anything any other Registrar cannot do. It's a hack, but it moves the DNSSEC ball forward, and doesn't require any new DNS "stuff" or Registry changes. 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 Wed, Nov 18, 2020 at 3:42 PM Peter van Dijk wrote: > On Tue, 2020-11-17 at 23:30 +, Tony Finch wrote: > [...] > > If (big if) we think it's worth upgrading the DNS delegation model (and > > EPP, and all the registries and registrars, and all the IPAM databases > and > > user interfaces, and documentation and textbooks), can we also tackle the > > scalability problem? By "scalability" I mean the need for a hosting > > provider to update N delegations when a server cert changes. And > there > > are decades old problems keeping delegation NS and glue and DS records > > correct. (A large chunk of the "it's always DNS" meme comes from how hard > > it is to understand delegations and update them correctly.) This whole > > area is a massive pain in the arse sorely in need of universal > automation. > > +100. I've referred to this in other threads - if CloudFlare had gotten > anywhere with their attempts to solve the operator / registrant / > registrar / registry disconnect problem, all of this would be so much > easier. > At ICANN69's DNSSEC Workshop last month, Steve Crocker issued a challenge to DNS Operators to organize and become an officially recognized constituency within ICANN. If that were to happen, then it might be able to address and solve some of these issues over time, given adequate engagement. > Any serious attempt at improving delegations needs to deal convincingly > > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so > > appallingly bad. > > Yes, or in the broader sense, my previous paragraph. > At the same workshop, Jim Galvin spoke about some of the structural reasons why it's challenging for the contracted gTLDs to make progress on supporting these (and also likely why there has only been adoption at a small number of ccTLDs, who are non-contracted parties). This was in relation to CDS and CDNSKEY. As far as I can tell, no-one has shown any interest in CSYNC to date. Shumon. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
Peter van Dijk 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.finchhttp://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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
Peter van Dijk wrote: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ > > As I understand the draft, the revalidation can happen in parallel to > the actual query the user is waiting for. Any setup/discovery of secure > transports would have to happen before that, so I'm not sure we can say > 'on top of delegation revalidation, TLSA lookups are basically free'. Yes, this still needs to be thought through more carefully, and measured in the real world. There are at least a couple of issues that worry me: * Exactly how bad is the extra latency? * How bad / avoidable are the lurking interop traps? Likely at least two flavours of the latter: due to asking for TLSA, or due to deeper iterative resolution into the nameserver's name's zone. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lough Foyle to Carlingford Lough: Southwest 6 to gale 8, veering northwest 7 to severe gale 9, increasing storm 10 for a time in North Channel, decreasing 3 to 5 later. Moderate or rough, becoming rough or very rough, occasionally high for a time in north. Squally showers. Moderate or good, occasionally poor. ___ 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 Tue, 2020-11-17 at 23:30 +, Tony Finch wrote: > Peter van Dijk wrote: > > The incremental cost for a resolver (doing a full resolution process > > for the TLSA records of one or more NS names) is not small, and neither > > are the latency costs. For 'popular' name servers, this cost can mostly > > be amortised, leaving the penalty with any domain hosted on a NSset > > that only has a few domains. > > Yes. However I think the relative cost of TLSA lookups is much less when a > resolver implements delegation revalidation because then it's fetching > authoritative A and anyway, so it can fetch TLSA concurrently. > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/ As I understand the draft, the revalidation can happen in parallel to the actual query the user is waiting for. Any setup/discovery of secure transports would have to happen before that, so I'm not sure we can say 'on top of delegation revalidation, TLSA lookups are basically free'. > > > 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. > > Or until the parent nameservers support authenticated encrypted > transports. The design choice that DNSSEC did not make, a long time ago. > Even so I think delegations should be signed. It would solve a *lot* of problems. > A (the?) major issue with this whole ADoT effort is the bad trade-off > between a delegation-centric design (where the DoT signal is in the parent > zone) which has really formidable deployment obstacles, and really > troublesome scalability issues; or a DNS-hosting-provider-centric design > which has poor performance and downgrade weaknesses. I know DOTPIN has been rejected/shelved/not-adopted for the deployment/scalability reasons you mention, and also because the problem space was not mapped out well enough yet, but I still wonder if perhaps it makes sense to have two solutions to the DPRIVE charter - one with short paths, few extra queries (like DOTPIN), and one that works well with '500k domains delegated to one party' - with delegations signed, or a non-pinning signal (that does not take part in key rollovers) on the 500k domains, etc. > If (big if) we think it's worth upgrading the DNS delegation model (and > EPP, and all the registries and registrars, and all the IPAM databases and > user interfaces, and documentation and textbooks), can we also tackle the > scalability problem? By "scalability" I mean the need for a hosting > provider to update N delegations when a server cert changes. And there > are decades old problems keeping delegation NS and glue and DS records > correct. (A large chunk of the "it's always DNS" meme comes from how hard > it is to understand delegations and update them correctly.) This whole > area is a massive pain in the arse sorely in need of universal automation. +100. I've referred to this in other threads - if CloudFlare had gotten anywhere with their attempts to solve the operator / registrant / registrar / registry disconnect problem, all of this would be so much easier. > Any serious attempt at improving delegations needs to deal convincingly > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so > appallingly bad. Yes, or in the broader sense, my previous paragraph. 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
Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
On Wed, 2020-11-18 at 10:14 -0500, Paul Wouters wrote: > On Mon, 16 Nov 2020, Brian Dickson wrote: > > > 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). > > The IP connection to (small) nameservers will always leak information, > even if perfectly encrypted and obtained without privacy. Just by > connecting to say ns1.nohats.ca, any observer knows you are connecting > to either "nohats.ca" or "libreswan.org". But not what subdomain, if any, of those you are visiting. I do recognise that this is on the long tail of things we can try to protect. > The only way out of that is a distributed decentralized DNS cache. I always imagined that, given DNSSEC, we could bittorrent our way out of this. Then later people imagined we could blockchain our way out of this - but it hasn't happened yet. > > 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. > > This is basically the same problem as ESNI. Except ESNI fixed it by > pulling information from (encrypted) DNS :) That's "protecting the NS records against snooping", if I understand you correctly. The other problem is protecting the delegation NS records against meddling, for which various partial solutions have been provided but we have zero standardised today. 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
Re: [dns-privacy] how can we ADoT?
On Tue, 2020-11-17 at 01:21 +, Tony Finch wrote: > 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 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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Revised opportunistic encryption draft
Brian Dickson wrote: > On Tue, Nov 17, 2020 at 3:30 PM Tony Finch wrote: > > > > Even so I think delegations should be signed. > > So, the parental NS records are not authoritative, and thus not supposed to > be signed. Yes, that was the logic, but it was a mistake :-) > The signer field would differ between the delegation RRSIG and the apex > RRSIG (on what would otherwise be very similar RRSETs). Yes, like RRSIG(NSEC). A change of this kind would need an algorithm bump to indicate support for the new semantics, like the bump from 5 to 7 to indicate support for NSEC3. This has the caveat that a signer will want to wait for a large enough proportion of validators to upgrade to support the new algorithms before the signer bumps its algorithm, because old validators will treat the new algorithms as insecure. > And I'm not sure whether the DPRIVE use case is enough of a "new > requirement" to justify changing the spec. But I think that is open to > consideration at least. Yes, that's why I'm talking about it :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger, Fisher, German Bight, Humber: Southwest 6 to gale 8, veering north 7 to severe gale 9. Rough or very rough, occasionally high for a time. Rain or showers. Moderate or good. ___ 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 Tue, Nov 17, 2020 at 3:30 PM Tony Finch wrote: > Peter van Dijk wrote: > > On Sat, 2020-10-31 at 13:52 -0700, 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. > > Or until the parent nameservers support authenticated encrypted > transports. > > Even so I think delegations should be signed. > So, the parental NS records are not authoritative, and thus not supposed to be signed. Has anyone ever experimented with how a signed delegation NS would be handled by resolvers? (This might vary by resolver software and possibly version.) The signer field would differ between the delegation RRSIG and the apex RRSIG (on what would otherwise be very similar RRSETs). I.e. if you had zone.example.net NS ns1.something.example.com (and friends), the apex RRSIG would have signer name zone.example.net, and the non-apex delegation RRSIG would have a different (shorter) signer name. Actually doing this as a protocol spec change would probably require that the delegation RRSIGs would need to be cached differently (in the same way the NS records are cached differently), and used accordingly. The standardization of DNSSEC was before my time, so I don't know to what degree this was discussed back then. As much as making changes to those RFCs would be difficult and potentially controversial, this might be the path of least implementation difficulty. The big thing would be the signing overhead on large authoritative (delegation-mostly) zones. And I'm not sure whether the DPRIVE use case is enough of a "new requirement" to justify changing the spec. But I think that is open to consideration at least. Fodder for discussion rather than a serious proposal, at least at this point. 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
Paul Wouters wrote: > On Tue, 17 Nov 2020, Tony Finch wrote: > > > Any serious attempt at improving delegations needs to deal convincingly > > with the quesion of why support for CDS, CDNSKEY, and CSYNC is so > > appallingly bad. > > Because IETF does not enforce sunsets of old stuff. The market has no > strong reason to move to support this new stuff, as there is a first > mover disadvantage with too many players. Look at Cloudflare, who is > very willing to do all these new things, and they are stuck with old > software/people at (sub)Registrars and Registries. > > This is also why DNSSEC is not ubiquitous. Yes, but I don't mean answer the question of what the difficulties are (we know the answers, I hope), I mean "deal with", counteract or avoid the difficulties. Any new work needs to be deployable: the IETF is supposed to be about running code, after all. If a proposal is heading in a direction that we know from past experience is not likely to be successful, then it needs a really solid argument why this time will be different. Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole, Lundy, Fastnet: West or northwest 6 to gale 8, occasionally severe gale 9 in Lundy and Fastnet, decreasing 3 to 5 later. Rough or very rough, occasionally moderate later. Showers. Moderate or good. ___ 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 Mon, 16 Nov 2020, Brian Dickson wrote: 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). The IP connection to (small) nameservers will always leak information, even if perfectly encrypted and obtained without privacy. Just by connecting to say ns1.nohats.ca, any observer knows you are connecting to either "nohats.ca" or "libreswan.org". The only way out of that is a distributed decentralized DNS cache. We have those, but they are under control of commercial enterprises, and most of them fall under 1 country's government. 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. This is basically the same problem as ESNI. Except ESNI fixed it by pulling information from (encrypted) DNS :) Paul ___ 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 Tue, 17 Nov 2020, Tony Finch wrote: Any serious attempt at improving delegations needs to deal convincingly with the quesion of why support for CDS, CDNSKEY, and CSYNC is so appallingly bad. Because IETF does not enforce sunsets of old stuff. The market has no strong reason to move to support this new stuff, as there is a first mover disadvantage with too many players. Look at Cloudflare, who is very willing to do all these new things, and they are stuck with old software/people at (sub)Registrars and Registries. This is also why DNSSEC is not ubiquitous. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
