Re: [dns-privacy] how can we ADoT? (with github url)

[Tony Finch <[e-mail]>]

Manu Bretelle <[e-mail]> 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.finch  <[e-mail]>  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.