Hello dprive.
I think that Ben Schwartz really hit nail on the head in his DSGLUE
presentation.
I suggest we _really_ try to get a better idea about design constraints
first, and work out their implications and protocol from there.
These are the crucial questions (copied and slightly modified from
https://datatracker.ietf.org/meeting/112/materials/slides-112-dprive-dsglue-01
slide 5):
* Can we slow down resolution of existing domains?
* Do we care about the latency of A2DoT-enabled domains?
* Do we care about A2DoT under non-A2DoT parents?
- i.e. protecting label N+1 after label N has leaked
- Can we require that non-A2DoT parents are signed?
* Can we add new RR types to the glue/parent side?
* Can the child atomically update NS/DS/glue RRSets together in the parent?
* Can we add new digest types to the DS record?
* Can we add DS RRs which do not constitute a valid DNSSEC-validation path?
(The last point was added by me. It equals to "Will RRR ecosystem accept
DS records which are really not a DNSSEC-validable path?".)
Let us try an experiment:
Could you please fill in yes/no in the following form, so we can quickly
see if there are totally different opinions or a rare agreement on some
of the points?
https://docs.google.com/forms/d/e/1FAIpQLSdllOX_cKT8L7bl8_jhxeQPsg1Iqam_rnD6iVVl_R4mnxBN1A/viewform
The form will close on:
Sunday 21th November 2021 23:59 UTC
Maybe it will move us a bit forward if we see some (common) red lines in
the answers. Or maybe not, we'll see.
P.S. Thank you Ben!
--
Petr Špaček
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
