Re: [dns-privacy] how can we ADoT?
On Wed, 2020-11-18 at 23:09 +, Tony Finch wrote: > > > * 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. Yes. > > > * 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. Ah, of course. Then you have the downsides of TLSA with the downsides of DOTPIN. > 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). That makes sense. 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?
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] 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] 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] how can we ADoT?
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. 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. 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'd like to assume that all transports offered by an NS host the ~same data (ignoring, for a moment, that we might one day imagine data that should only be seen over transports with certain security properties, but I'm imagining that such data would not cover whole zones). In fact, it would be good if I don't assume. Instead, we should actively decide whether any such splits are allowed, or forbidden. I note that the phase2 doc has this text: 9. A given name server may be authoritative for multiple zones. As such, a name server MAY support use of a secure transport protocol for one zone, but not for another. So in fact, right now we have written down that this is allowed. But I think it is a mistake. 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? (with github url)
Manu Bretelle wrote: > The "cloud provider" case, e.g few name servers for many zones is also > tricky. I prefer to think of this as the normal common case, since I'm not a cloud provider and I have many more zones than servers :-) > I think in those cases, TLSA may be the best bet as this is under > control of the nameserver, not the zone operator. Then there may be issue > with being able to opt people in/out. I think in any cases, if you want to > be able to gradually enroll your customers while giving the the choice to > not be enrolled, you essentially need to provide them with a new NS that > supports ADoT and have them move over. Yes. It can be just different aliases for the same server, where the aliases differ in whether they have associated TLSA records or not. (I need to write more about nameserver aliases.) > That hint could be downgraded, but if not, can be used to fetch the TLSA > record over an unauthenticated TLS connection and then validating it. I > suppose it just obfuscate the zone, which may be useful *if* multiple name > server names are behind the same IP and/or name server name matches the > zone name (because TLSA record would be against name server name, not zone). > Unless the query to the parent zone was using ADoT, that information may > already be known from someone on-path. Yes. (I think I covered all those points in my notes.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle: South 6 to gale 8. Rough or very rough, occasionally high in northwest. Rain or squally showers. 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? (with github url)
On Wed, Nov 11, 2020 at 4:00 PM Tony Finch wrote: > Manu Bretelle wrote: > > > > Totally fair, pretty sure there were no speaker notes ;) . The > > presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . > > Originally, there was this draft > > > https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 > > and the solutions in the slide deck were compiled from feedback/ideas > that > > came up while talking with other folks. > > Ooh, that video has lots of ideas, thanks! I think most of them are > slightly different angles on approaches that I rejected in my notes. (how > do I do a wry emoticon?) I'll try to summarise - please forgive me if I > have misunderstood... > > * DSPKI: vaguely dnscurve flavoured delegations, but putting an X.509 > SPKI into a new delegation RRtype. Comes under my "new kind of > delegation" heading. > The penultimate slide is a dnscurve like approach. > > (There's a twist that DSPKI seems to have an authenticator per zone, > so all servers are expected to share the same private key?) > yes and no, you could have multiple DSPKI records, but it is definitely an all or nothing, as in all servers would need to provide DoT. > > * Do9: per-server encryption hint without authenticator inside DS > records. Most of the badness under my "new DS algorithm" heading, > but with less key rollover churn. WebPKI authentication. > yop > > Joe Abley emphasized what I called the scalability issue. Wes Hardaker > made a slightly different point about correctness and synchronization of > apex and delegation records. Wes's point kind of strengthens the > scalability issue: a design that avoids per-zone configuration of any > kind for scalability reasons also avoids delegation mismatch problems. > yes, anything that will involve the parent will be a nightmare to keep synchronized unless stuff like CDS, CDNSKEY ... hence CDSPKI work, well as much as synchronisation is concerned. The "cloud provider" case, e.g few name servers for many zones is also tricky. I think in those cases, TLSA may be the best bet as this is under control of the nameserver, not the zone operator. Then there may be issue with being able to opt people in/out. I think in any cases, if you want to be able to gradually enroll your customers while giving the the choice to not be enrolled, you essentially need to provide them with a new NS that supports ADoT and have them move over. > Watson Ladd made a good point about decoupling signalling from > authentication. My prejudice was that if you are publishing a 1 bit ADoT > signal in the DNS you might as well publish a 256 bit authenticator; now > that I have gone through the options in detail I still think that is true. > And I think it implies that any approach to ADoT based on in-band > signalling should avoid relying on any records published in the DNS, > because then the in-band signal no longer does anything useful. > Decoupling signalling from authenticating could actually let zone owner decide to not do ADoT even though the provider supports it. > > [ I've been very bad at looking for and citing previous work, sorry > everyone... I belatedly realise the datatracker doesn't list expired > drafts, oops ] > > > Speaking of which, I think Brian Dickson did a good job of describing an > > "hybrid" approach which I had notes of, but never got to write down > > properly. Here is the link: > > > https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/ > > Yes, I think Brian's description is basically the same as what I have in > mind. On top of that I've added a little complication, `dot--` hints so > that when a delegation requires glue, a resolver can still connect > directly over TLS without first getting the TLSA records. I am unsure if > these hints are really needed... > That hint could be downgraded, but if not, can be used to fetch the TLSA record over an unauthenticated TLS connection and then validating it. I suppose it just obfuscate the zone, which may be useful *if* multiple name server names are behind the same IP and/or name server name matches the zone name (because TLSA record would be against name server name, not zone). Unless the query to the parent zone was using ADoT, that information may already be known from someone on-path. Manu > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Channel Islands: South to southeast 6 to 7, locally gale 8 with gusts to > 50kt, > veering west to southwest 5 to 7 before midnight, decreasing 4 to 5 around > dawn, locally 6 mid-channel, backing southwest to south in the afternoon. > Rather rough to rough, occasionally moderate in the south and east, > becoming > slight in the south to rather rough in the north by midday, perhaps locally > rough mid-channel, with a low swell throughout. Rain, locally heavy, > clearing > before midnight to isolated showers. Good, occasionally moderate to poor > this > evening. >
Re: [dns-privacy] how can we ADoT? (with github url)
Manu Bretelle wrote: > > Totally fair, pretty sure there were no speaker notes ;) . The > presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . > Originally, there was this draft > https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 > and the solutions in the slide deck were compiled from feedback/ideas that > came up while talking with other folks. Ooh, that video has lots of ideas, thanks! I think most of them are slightly different angles on approaches that I rejected in my notes. (how do I do a wry emoticon?) I'll try to summarise - please forgive me if I have misunderstood... * DSPKI: vaguely dnscurve flavoured delegations, but putting an X.509 SPKI into a new delegation RRtype. Comes under my "new kind of delegation" heading. (There's a twist that DSPKI seems to have an authenticator per zone, so all servers are expected to share the same private key?) * Do9: per-server encryption hint without authenticator inside DS records. Most of the badness under my "new DS algorithm" heading, but with less key rollover churn. WebPKI authentication. Joe Abley emphasized what I called the scalability issue. Wes Hardaker made a slightly different point about correctness and synchronization of apex and delegation records. Wes's point kind of strengthens the scalability issue: a design that avoids per-zone configuration of any kind for scalability reasons also avoids delegation mismatch problems. Watson Ladd made a good point about decoupling signalling from authentication. My prejudice was that if you are publishing a 1 bit ADoT signal in the DNS you might as well publish a 256 bit authenticator; now that I have gone through the options in detail I still think that is true. And I think it implies that any approach to ADoT based on in-band signalling should avoid relying on any records published in the DNS, because then the in-band signal no longer does anything useful. [ I've been very bad at looking for and citing previous work, sorry everyone... I belatedly realise the datatracker doesn't list expired drafts, oops ] > Speaking of which, I think Brian Dickson did a good job of describing an > "hybrid" approach which I had notes of, but never got to write down > properly. Here is the link: > https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/ Yes, I think Brian's description is basically the same as what I have in mind. On top of that I've added a little complication, `dot--` hints so that when a delegation requires glue, a resolver can still connect directly over TLS without first getting the TLSA records. I am unsure if these hints are really needed... Tony. -- f.anthony.n.finchhttp://dotat.at/ Channel Islands: South to southeast 6 to 7, locally gale 8 with gusts to 50kt, veering west to southwest 5 to 7 before midnight, decreasing 4 to 5 around dawn, locally 6 mid-channel, backing southwest to south in the afternoon. Rather rough to rough, occasionally moderate in the south and east, becoming slight in the south to rather rough in the north by midday, perhaps locally rough mid-channel, with a low swell throughout. Rain, locally heavy, clearing before midnight to isolated showers. Good, occasionally moderate to poor this evening. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT? (with github url)
On Wed, Nov 11, 2020 at 1:20 PM Tony Finch wrote: > Manu Bretelle wrote: > > > Having this as an ID or possibly a github repo may make it easier to > refer > > to/iterate than just this email. > > Yes! https://github.com/fanf2/draft-dprive-adot Thanks! > > > > I had attempted to quickly categorize some of those approaches (albeit a > > much smaller list) in a matrix in [0] but did not follow through since. > > > > [0] > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 > > Ah, I haven't been paying enough attention to meetings so I missed this! I > think I need the speaker notes to understand it properly :-) > Totally fair, pretty sure there were no speaker notes ;) . The presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . Originally, there was this draft https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 and the solutions in the slide deck were compiled from feedback/ideas that came up while talking with other folks. > > Your title "DoT for insecure delegations" is interesting: one of the > problems with what I have written so far is that it is too much a post-hoc > justification for using TLSA records to support ADoT. So I have built > nameserver authentication on top of TLSA on top of DNSSEC. > Speaking of which, I think Brian Dickson did a good job of describing an "hybrid" approach which I had notes of, but never got to write down properly. Here is the link: https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/ My TL;DRed notes, in the context of serving zones across name servers in (multiple) out-of-bailiwick zones, that I think echoes Brian's more throughout description: Other approaches to signalling DoT support to the recursive nameservers may be through the presence of TLSA record, special record at the name server side. In the end, the name server zone owner will have to be authoritative, such authoritative answer can only be validated if it is signed. By separating zones from nameservers, one can provide DNSSEC signing at the name server zone level without having to enforce it at the zones which are served. Having multiple name server zones would: - allow enabling DNSSEC on a subset of the nameservers without risking impacting all the DNS traffic. - allow to stage key roll on a subset of the nameservers, and ensuring that in the worst case, only a subset of the traffic is impacted in case of mishap. > One of my unstated assumptions is that DoT will be problematic for TLDs, > and (with QNAME minimization) it matters more for leaf zones, so it is > likely to be deployed there first. But DNSSEC is deployed to a much higher > proportion of TLDs than leaf zones, so there's a good chance I'm wrong. > yeah, and this is where zones hosted by DNS providers may benefit of this hybrid approach if the providers are supporting DNSSEC for their name server zones. But I just quickly checked Route53 and Google Domain, and none of them have their NS names signed. Manu > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Shetland Isles: Southerly 6 to gale 8, decreasing 4 or 5 later in west. > Rough > or very rough. Rain or drizzle. Moderate or poor, becoming good later in > west. > ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
On 11/11/2020 20:32, Manu Bretelle wrote: Thanks Tony for the exhaustive list of approaches with their pros and cons, +many - very useful, Thanks, S. OpenPGP_0x5AB2FAF17B172BEA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote: > I haven't seen anything written down that explains why it is difficult to > do DoT to authoritative servers. There was a good discussion earlier this > year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some > of the issues. I have done a braindump that attempts to cover all the > angles reasonably systematically. I expect I haven't quite reached that > goal though, so I hope this will provoke some informative comments :-) > Since draft submission is closed, I'll paste it here for your delectation. > > > ## Explicit encryption support signal > > How can a resolver know an authoritative server supports encryption? > There are three basic alternatives: > > 1. No explicit signal: the resolver tries to make an encrypted > connection, and falls back to cleartext if it gets an ICMP > unreachable error or connection timeout. > > This is problematic because connection timeouts can be very slow, > especially if the resolver tries multiple encrypted transports. > This is also is vulnerable to downgrade attacks. > > The working group consensus is that an explicit signal is > required. > > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > resolver starts by connecting in the clear, and upgrades to an > encrypted connection if the authoritative server supports it. > > This is vulnerable to downgrade attacks. The initial cleartext > connection adds latency, and would need to be specified carefully > to avoid privacy leaks. > > 3. Signal in DNS records: the resolver makes extra queries during > iterative resolution to find out whether an authoritative server > supports encryption, before the resolver connects to it. > > The extra queries add latency, though that can be mitigated by > querying concurrently, and by placing the new records on the > existing resolution path. > > DNSSEC can provide authentication and downgrade protection. > > This specification takes the last option, since it is best for > security and not too bad for performance. > Agree strongly, for the reasons you mention. > > > ## Where can nameserver encryption records go? > > Where can we put the new DNS records to signal that a nameserver > supports encryption? There are a number of issues to consider: > > 1. Performance: we don't want the extra queries to slow down > resolution too much; > > 2. Scalability: is encryption configured per nameserver? per zone? > Also: Per (anycast) instance/location? Per operator? Per tuple (for whatever N-tuple of factors makes sense, like (zone, operator, location, nameserver)? > > 3. Authentication: DNSSEC does not protect delegation NS records or > glue address records; > At worst that allows MITM observation, and perhaps DOS, but cannot invalide the authentication itself otherwise. > > 4. DNS data model: we ought to re-use existing RRtypes according to > their intended purpose; > > 5. DNS extensibility: make use of well-oiled upgrade points and > avoid changes that have a track record of very slow deployment; > > 6. EPP compatibility: a zone's delegation is usually managed via the > Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731] > [@?RFC5732] so any changes need to work with EPP. > > The following subsections discuss the possible locations, and explain > why most of them have been rejected. > > > ## In the reverse DNS? > > Given a nameserver's IP address, a resolver might make a query like > > _853._tcp.1.2.0.192.in-addr.arpa.TLSA? > > This possibility is rejected because: > > * It would be very slow: after receiving a referral, a resolver > would have to iterate down the reverse DNS, instead of immediately > following the referral. > > * At the moment the reverse DNS refers to the forward DNS for NS > records; this would also make the forward DNS refer to the reverse > DNS for TLSA records. Dependency loops are best avoided. > > * It's often difficult to put arbitrary records in the reverse DNS. > > * 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. > > > ## A new kind of delegation? > > In theory, DNSSEC provides a way to update the DNS data model, along > the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea > is to introduce new DNSSEC algorithm types which indicate that a zone can > include new types of records that need special validation logic. > Existing validators will be able to resolve names in the zone, but > will treat it as insecure. > > We might use this upgrade strategy to introduce new delegation records > that indicate support for transport encryption. However, it would > require a very long deployment timeline. It would also require a > corresponding upgrade
Re: [dns-privacy] how can we ADoT?
Thanks Tony for the exhaustive list of approaches with their pros and cons, helping in deciding where the tradeoff may be made. Having this as an ID or possibly a github repo may make it easier to refer to/iterate than just this email. I had attempted to quickly categorize some of those approaches (albeit a much smaller list) in a matrix in [0] but did not follow through since. Thanks, Manu [0] https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote: > I haven't seen anything written down that explains why it is difficult to > do DoT to authoritative servers. There was a good discussion earlier this > year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some > of the issues. I have done a braindump that attempts to cover all the > angles reasonably systematically. I expect I haven't quite reached that > goal though, so I hope this will provoke some informative comments :-) > Since draft submission is closed, I'll paste it here for your delectation. > > > ## Explicit encryption support signal > > How can a resolver know an authoritative server supports encryption? > There are three basic alternatives: > > 1. No explicit signal: the resolver tries to make an encrypted > connection, and falls back to cleartext if it gets an ICMP > unreachable error or connection timeout. > > This is problematic because connection timeouts can be very slow, > especially if the resolver tries multiple encrypted transports. > This is also is vulnerable to downgrade attacks. > > The working group consensus is that an explicit signal is > required. > > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > resolver starts by connecting in the clear, and upgrades to an > encrypted connection if the authoritative server supports it. > > This is vulnerable to downgrade attacks. The initial cleartext > connection adds latency, and would need to be specified carefully > to avoid privacy leaks. > > 3. Signal in DNS records: the resolver makes extra queries during > iterative resolution to find out whether an authoritative server > supports encryption, before the resolver connects to it. > > The extra queries add latency, though that can be mitigated by > querying concurrently, and by placing the new records on the > existing resolution path. > > DNSSEC can provide authentication and downgrade protection. > > This specification takes the last option, since it is best for > security and not too bad for performance. > > > ## Where can nameserver encryption records go? > > Where can we put the new DNS records to signal that a nameserver > supports encryption? There are a number of issues to consider: > > 1. Performance: we don't want the extra queries to slow down > resolution too much; > > 2. Scalability: is encryption configured per nameserver? per zone? > > 3. Authentication: DNSSEC does not protect delegation NS records or > glue address records; > > 4. DNS data model: we ought to re-use existing RRtypes according to > their intended purpose; > > 5. DNS extensibility: make use of well-oiled upgrade points and > avoid changes that have a track record of very slow deployment; > > 6. EPP compatibility: a zone's delegation is usually managed via the > Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731] > [@?RFC5732] so any changes need to work with EPP. > > The following subsections discuss the possible locations, and explain > why most of them have been rejected. > > > ## In the reverse DNS? > > Given a nameserver's IP address, a resolver might make a query like > > _853._tcp.1.2.0.192.in-addr.arpa.TLSA? > > This possibility is rejected because: > > * It would be very slow: after receiving a referral, a resolver > would have to iterate down the reverse DNS, instead of immediately > following the referral. > > * At the moment the reverse DNS refers to the forward DNS for NS > records; this would also make the forward DNS refer to the reverse > DNS for TLSA records. Dependency loops are best avoided. > > * It's often difficult to put arbitrary records in the reverse DNS. > > * 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. > > > ## A new kind of delegation? > > In theory, DNSSEC provides a way to update the DNS data model, along > the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea > is to introduce new DNSSEC algorithm types which indicate that a zone can > include new types of records that need special validation logic. > Existing validators will be able to resolve names in the zone, but > will treat it as insecure. > > We might use this upgrade strategy to introduce new
Re: [dns-privacy] how can we ADoT?
Eric Rescorla wrote: > On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote: > > > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > > resolver starts by connecting in the clear, and upgrades to an > > encrypted connection if the authoritative server supports it. > > > > This is vulnerable to downgrade attacks. The initial cleartext > > connection adds latency, and would need to be specified carefully > > to avoid privacy leaks. > > It's worth noting that one could add an HSTS-like mechanism here. Given > that a lot of requests are probably return customers, this would likely > result in quite a lot of lift. Good point, thanks! I haven't thought about this option enough. One thing that will make it more tricky is nameserver aliases: it's relatively common for NS records to refer to servers by names that the server operator does not know. So I expect that an in-band upgrade to TLS will have to use IP-address-based authentication, if any. A nice thing about TLSA records is they also tell the client what name to look for in the server's cert. (I need to make that more explicit in my notes.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: In southeast, easterly 4 to 6. In northwest, southwesterly 5 to 7, becoming cyclonic 4 or 5 later. In southeast, moderate. in northwest, moderate becoming rough. In southeast, fair. In northwest, showers. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
Hollenbeck, Scott wrote: > > It's not an EPP limitation. We can always define an EPP extension to add > information to the parent zone. The issue is if the zone administrator > can/will publish that information in the zone and if EPP clients are able and > willing to provide it. True! I am using "EPP" as a grossly unfair and simplified shorthand for the whole registry/registrar ecosystem. TBH I think most of the difficulties are in registrar user interfaces and APIs, rather than EPP. I would be very grateful if someone could write a more informed and accurate description of the registr* aspects of how feasible it might be to change the domain delegation model. If it's worth revising these notes I will change this part to be less lazy. Thanks for reading and it and giving feedback! Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall: Northwest 3 to 5 backing south 7 to severe gale 9, perhaps storm 10 later. Rough, becoming very rough or high. Rain. Moderate becoming poor. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] how can we ADoT?
> -Original Message- > From: dns-privacy On Behalf Of Tony Finch > Sent: Wednesday, November 11, 2020 2:07 PM > To: dns-privacy@ietf.org > Subject: [EXTERNAL] [dns-privacy] how can we ADoT? > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > I haven't seen anything written down that explains why it is difficult to do > DoT to authoritative servers. There was a good discussion earlier this year > about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some of the > issues. I have done a braindump that attempts to cover all the angles > reasonably systematically. I expect I haven't quite reached that goal > though, > so I hope this will provoke some informative comments :-) Since draft > submission is closed, I'll paste it here for your delectation. > > > ## Explicit encryption support signal > > How can a resolver know an authoritative server supports encryption? > There are three basic alternatives: > > 1. No explicit signal: the resolver tries to make an encrypted > connection, and falls back to cleartext if it gets an ICMP > unreachable error or connection timeout. > > This is problematic because connection timeouts can be very slow, > especially if the resolver tries multiple encrypted transports. > This is also is vulnerable to downgrade attacks. > > The working group consensus is that an explicit signal is > required. > > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > resolver starts by connecting in the clear, and upgrades to an > encrypted connection if the authoritative server supports it. > > This is vulnerable to downgrade attacks. The initial cleartext > connection adds latency, and would need to be specified carefully > to avoid privacy leaks. > > 3. Signal in DNS records: the resolver makes extra queries during > iterative resolution to find out whether an authoritative server > supports encryption, before the resolver connects to it. > > The extra queries add latency, though that can be mitigated by > querying concurrently, and by placing the new records on the > existing resolution path. > > DNSSEC can provide authentication and downgrade protection. > > This specification takes the last option, since it is best for security and > not too > bad for performance. > > > ## Where can nameserver encryption records go? > > Where can we put the new DNS records to signal that a nameserver supports > encryption? There are a number of issues to consider: > > 1. Performance: we don't want the extra queries to slow down > resolution too much; > > 2. Scalability: is encryption configured per nameserver? per zone? > > 3. Authentication: DNSSEC does not protect delegation NS records or > glue address records; > > 4. DNS data model: we ought to re-use existing RRtypes according to > their intended purpose; > > 5. DNS extensibility: make use of well-oiled upgrade points and > avoid changes that have a track record of very slow deployment; > > 6. EPP compatibility: a zone's delegation is usually managed via the > Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731] > [@?RFC5732] so any changes need to work with EPP. > > The following subsections discuss the possible locations, and explain why > most of them have been rejected. > > > ## In the reverse DNS? > > Given a nameserver's IP address, a resolver might make a query like > > _853._tcp.1.2.0.192.in-addr.arpa.TLSA? > > This possibility is rejected because: > > * It would be very slow: after receiving a referral, a resolver > would have to iterate down the reverse DNS, instead of immediately > following the referral. > > * At the moment the reverse DNS refers to the forward DNS for NS > records; this would also make the forward DNS refer to the reverse > DNS for TLSA records. Dependency loops are best avoided. > > * It's often difficult to put arbitrary records in the reverse DNS. > > * 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. > > > ## A new kind of delegation? > > In theory, DNSSEC provides a way to update the DNS data model, along the > lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea is to > introduce new DNSSEC algorithm types which indicate that a zone can include > new types of records that need special
Re: [dns-privacy] how can we ADoT?
On Wed, Nov 11, 2020 at 11:07 AM Tony Finch wrote: > 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the > resolver starts by connecting in the clear, and upgrades to an > encrypted connection if the authoritative server supports it. > > This is vulnerable to downgrade attacks. The initial cleartext > connection adds latency, and would need to be specified carefully > to avoid privacy leaks. > It's worth noting that one could add an HSTS-like mechanism here. Given that a lot of requests are probably return customers, this would likely result in quite a lot of lift. -Ekr > 3. Signal in DNS records: the resolver makes extra queries during > iterative resolution to find out whether an authoritative server > supports encryption, before the resolver connects to it. > > The extra queries add latency, though that can be mitigated by > querying concurrently, and by placing the new records on the > existing resolution path. > > DNSSEC can provide authentication and downgrade protection. > > This specification takes the last option, since it is best for > security and not too bad for performance. > > > ## Where can nameserver encryption records go? > > Where can we put the new DNS records to signal that a nameserver > supports encryption? There are a number of issues to consider: > > 1. Performance: we don't want the extra queries to slow down > resolution too much; > > 2. Scalability: is encryption configured per nameserver? per zone? > > 3. Authentication: DNSSEC does not protect delegation NS records or > glue address records; > > 4. DNS data model: we ought to re-use existing RRtypes according to > their intended purpose; > > 5. DNS extensibility: make use of well-oiled upgrade points and > avoid changes that have a track record of very slow deployment; > > 6. EPP compatibility: a zone's delegation is usually managed via the > Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731] > [@?RFC5732] so any changes need to work with EPP. > > The following subsections discuss the possible locations, and explain > why most of them have been rejected. > > > ## In the reverse DNS? > > Given a nameserver's IP address, a resolver might make a query like > > _853._tcp.1.2.0.192.in-addr.arpa.TLSA? > > This possibility is rejected because: > > * It would be very slow: after receiving a referral, a resolver > would have to iterate down the reverse DNS, instead of immediately > following the referral. > > * At the moment the reverse DNS refers to the forward DNS for NS > records; this would also make the forward DNS refer to the reverse > DNS for TLSA records. Dependency loops are best avoided. > > * It's often difficult to put arbitrary records in the reverse DNS. > > * 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. > > > ## A new kind of delegation? > > In theory, DNSSEC provides a way to update the DNS data model, along > the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea > is to introduce new DNSSEC algorithm types which indicate that a zone can > include new types of records that need special validation logic. > Existing validators will be able to resolve names in the zone, but > will treat it as insecure. > > We might use this upgrade strategy to introduce new delegation records > that indicate support for transport encryption. However, it would > require a very long deployment timeline. It would also require a > corresponding upgrade to EPP. > > This is much too difficult. > > > ## Non-delegation records in the parent zone? > > Although it's extremely difficult to change which DNS records can > appear at a delegation, in principle the parent zone could contain > information about a delegation in a separate subdomain, like > > zone.example.NSns1.zone.example. > zone.example.NSns2.zone.example. > _853._tcp.ns1.zone._dot.example.TLSA (...) > _853._tcp.ns2.zone._dot.example.TLSA (...) > > The `_dot` tag makes the TLSA records into authoritative data in the > parent zone, rather than non-authoritative glue-like records. To > improve performance, the parent zone's nameservers could include these > records in referrals as additional data. The resolver could > authenticate them with DNSSEC and immediately use an encrypted > connection to the child zone's nameservers. > > Although this idea would be secure and fast and compatible with the > DNS, it is incompatible with EPP, so it is not realistically > deployable. > > > ## New DS record algorithm? > > The basic idea is to introduce a special DNSSEC algorithm number that > can be used in DS records to indicate support for encryption. This > runs into a number of problems, ultimately because it's
[dns-privacy] how can we ADoT?
I haven't seen anything written down that explains why it is difficult to do DoT to authoritative servers. There was a good discussion earlier this year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some of the issues. I have done a braindump that attempts to cover all the angles reasonably systematically. I expect I haven't quite reached that goal though, so I hope this will provoke some informative comments :-) Since draft submission is closed, I'll paste it here for your delectation. ## Explicit encryption support signal How can a resolver know an authoritative server supports encryption? There are three basic alternatives: 1. No explicit signal: the resolver tries to make an encrypted connection, and falls back to cleartext if it gets an ICMP unreachable error or connection timeout. This is problematic because connection timeouts can be very slow, especially if the resolver tries multiple encrypted transports. This is also is vulnerable to downgrade attacks. The working group consensus is that an explicit signal is required. 2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the resolver starts by connecting in the clear, and upgrades to an encrypted connection if the authoritative server supports it. This is vulnerable to downgrade attacks. The initial cleartext connection adds latency, and would need to be specified carefully to avoid privacy leaks. 3. Signal in DNS records: the resolver makes extra queries during iterative resolution to find out whether an authoritative server supports encryption, before the resolver connects to it. The extra queries add latency, though that can be mitigated by querying concurrently, and by placing the new records on the existing resolution path. DNSSEC can provide authentication and downgrade protection. This specification takes the last option, since it is best for security and not too bad for performance. ## Where can nameserver encryption records go? Where can we put the new DNS records to signal that a nameserver supports encryption? There are a number of issues to consider: 1. Performance: we don't want the extra queries to slow down resolution too much; 2. Scalability: is encryption configured per nameserver? per zone? 3. Authentication: DNSSEC does not protect delegation NS records or glue address records; 4. DNS data model: we ought to re-use existing RRtypes according to their intended purpose; 5. DNS extensibility: make use of well-oiled upgrade points and avoid changes that have a track record of very slow deployment; 6. EPP compatibility: a zone's delegation is usually managed via the Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731] [@?RFC5732] so any changes need to work with EPP. The following subsections discuss the possible locations, and explain why most of them have been rejected. ## In the reverse DNS? Given a nameserver's IP address, a resolver might make a query like _853._tcp.1.2.0.192.in-addr.arpa.TLSA? This possibility is rejected because: * It would be very slow: after receiving a referral, a resolver would have to iterate down the reverse DNS, instead of immediately following the referral. * At the moment the reverse DNS refers to the forward DNS for NS records; this would also make the forward DNS refer to the reverse DNS for TLSA records. Dependency loops are best avoided. * It's often difficult to put arbitrary records in the reverse DNS. * 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. ## A new kind of delegation? In theory, DNSSEC provides a way to update the DNS data model, along the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea is to introduce new DNSSEC algorithm types which indicate that a zone can include new types of records that need special validation logic. Existing validators will be able to resolve names in the zone, but will treat it as insecure. We might use this upgrade strategy to introduce new delegation records that indicate support for transport encryption. However, it would require a very long deployment timeline. It would also require a corresponding upgrade to EPP. This is much too difficult. ## Non-delegation records in the parent zone? Although it's extremely difficult to change which DNS records can appear at a delegation, in principle the parent zone could contain information about a delegation in a separate subdomain, like zone.example.NSns1.zone.example. zone.example.NSns2.zone.example. _853._tcp.ns1.zone._dot.example.TLSA (...) _853._tcp.ns2.zone._dot.example.TLSA (...) The `_dot` tag makes the TLSA records into authoritative data in the parent
