On Wed, Nov 11, 2020 at 4:00 PM Tony Finch <d...@dotat.at> wrote: > Manu Bretelle <chan...@gmail.com> 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.finch <d...@dotat.at> http://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
