Ben, I've reviewed the draft, thanks for writing it up. I do think it's an excellent shot at addressing the problem of authenticated encryption, and very mature already. Speaking as a TLD registry operator, i agree that the glue provisioning path is extremely slow to upgrade, so "staying under the radar" by using an existing, reasonably well deployed RR type is the only feasible "fast" way forward (for medium values of "fast", as it will take some time and effort for the new algorithm type to be enabled). Getting wide deployment for an EPP extension to provision SVCB directly would take at least a decade.. - So, i like this alternative a lot.
However, i'm a bit more cautious when it comes to generalizing DS-GLUE to other use cases, particularly conveying NS records. It's cool to have a generic mechanism to convey arbitrary records, but once those records overlap with a "legacy deployment", we need to be very very careful about the interactions between those two channels (eg. domain name owners expecting they can safely remove the NS records from the registry, because they supply those records in DS-GLUE already). I think there should be some text in the draft about this in future revisions. Maybe we should even restrict DS-GLUE to a set of pre-defined use cases. best, Alex On Tue, Aug 10, 2021 at 7:26 PM Ben Schwartz <[email protected]> wrote: > > I've now uploaded > https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-01, with > clarifications and corrections based on comments from Paul Hoffman and Ilari > Liusvaara (thanks both). > > On Tue, Aug 10, 2021 at 12:16 PM Paul Hoffman <[email protected]> wrote: >> >> >> Hi DPRIVE. I've written this up as a proper I-D at >> >> https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-00. Please >> >> review. >> >> Peter and I talked yesterday, and we see how to update >> draft-ietf-dprive-unauth-to-authoritative to incorporate "if you're a >> validating resolver, you SHOULD process DSGLUE during the NS lookup so that >> you might be able to encrypt the first time". This model seems to be the >> best so far to give the needed information in the parent. It would be good >> to hear if the WG wants to go in this direction. >> >> --Paul Hoffman_______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
