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
