Hiya,
On 25/05/2021 22:16, Tim Wicinski wrote:
All The authors took the advice from the working group and extracted the more common features into a separate document. The chairs would like the working group to give some comments, as we feel a document like this should be considered for adoption.
I think it might be useful to adopt such a document. But there is a risk that it turns out to be a waste of time if it ends up more as a tool (ab)used in arguments about which direction(s) to take rather than a bit of spec text that's common to >1 approach. So, I'm not sure if adopting this soon would be a good idea or not. WRT a couple of other points mentioned in the thread: - "Authenticated" has been used in two different ways. For TLS, what's authenticated is the NS. For DNSSEC, what's authenticated is the zone signing entity. Those are not the same entities in almost cases so it'd be better to try hard to not confuse those. - SVCB in the parent zone will take years to happen, if it ever does, other than sporadically. The equivalent "DS in the parent" problem is IMO a major reason why DNSSEC has not been a success. I've not seen any credible argument as to why it'd be easier to get SCVB into parent zones. On the draft itself: - The draft seemed ambiguous to me about how the SVCB gets into a resolver's cache, maybe that's ok to fix in a bit, or maybe it'd differ with different approaches, but the authors' intent wasn't clear to this reader. - I didn't get the intended behaviour when the "use TLS" signal is seen, but not for all NS instances. (Maybe that's in the pesudocode, but I didn't read that bit sorry;-) Cheers, S. PS: I'm one of those who do think an opportunistic mode is worthwhile exploring as a stepping stone to an eventual mode with TLS server auth.
https://datatracker.ietf.org/doc/draft-pp-dprive-common-features/ https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt Please read and comment on this draft. thanks tim>---------- Forwarded message --------- From: Paul Hoffman <paul.hoff...@icann.org> Date: Wed, May 19, 2021 at 12:59 PM Subject: [dns-privacy] New draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features To: dpr...@ietf.org <dpr...@ietf.org> Greetings again. Peter and I have revised draft-ietf-dprive-unauth-to-authoritative and draft-pp-dprive-common-features based on recent mailing list traffic. One major change is that we realized that we could move even more sections from unauth-to-authoritative to common-features because they would apply to the fully-authenticated use case. Please review them to see if you agree. If people like the idea of us splitting out common features, it would be good if it too became a WG document, particularly to help focus the discussions on the unauthenticated and fully-authenticated use cases. --Paul Hoffman and Peter van Dijk https://www.ietf.org/archive/id/draft-pp-dprive-common-features-01.txt https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-01.txt _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
