"Hollenbeck, Scott" <[email protected]> writes:
> One "already being used" example that I've recently seen > (https://ant.isi.edu/events/dinr2023/S/s43.pdf) describes itself as > "research" > and an "experiment". Not as a prototype, or a proof of concept, but as > research and an experiment. That description aligns much more closely with > Experimental status than Proposed Standard status. I've asked Wes privately > if > he could provide his own perspective. Sorry for the delay on this. Back to back conferences and I needed to re-read the draft before responding (though I'll note it may have been updated again since my reading). A few points: yes, we've deployed TLS at b.root-servers.net [1] as an experiment to help the world determine whether or not TLS at the root is viable and useful [2], and help resolvers create a path through the issue when only some of the authoritative servers for a given zone have deployed TLS (with the expectation that we may be the only RSO deploying TLS in the near future). One critical thing: don't use *our* experiment to decide whether or not the *protocol* is an experiment or not. It could easily go either way -- we're trying an experiment at the root level and deem it an experiment not because the protocol may or may not be an experiment, but rather because we MUST prioritize UDP/TCP service at this time and as such reserve the right to turn off TLS at a moments notice if we find it is negatively impacting our UDP/TCP service levels. One final note about our implementation: it's not an implementation. We are re-using an existing implementation (bind) in our deployment and much of the draft's requirements/etc are targeted toward people writing code. We did not touch the code, we only touched ./configure arguments and configuration files to deploy our experiment. Sections 3 and 4 say they're writing guidance for servers, but they really mean guidance for the code not the deployment (at least mostly). Having said that, I'll continue with my thoughts about the draft regardless of our RSO's experimental deployment. > [SAH] I am suggesting that it SHOULD be described as a research effort > because > of the specification gaps. Is it really a great idea to publish a Proposed > Standard that includes a normative reference that explicitly says that it > wasn't designed for this specific purpose? If this document updates the normative reference with a statement saying "now it's designed for this purpose", that's not a problem. So it's very possible that this document could go forward as a proposed standard without a problem. But... it do so, it should probably be considered as generally stable, complete and hopefully unlikely to change in the future [of course many standards do change and "recycle at proposed", but they generally shouldn't be thinking ahead of time that this will happen]. To me, having read the draft, it *reads* more like at experiment at this time for some of it and *feels* like it should be an experiment for others. But that could be changed with a pass that alters the text a bit. I do wonder if such a complicated set of timing recordings is necessary or whether or not it could be simplified in the future to require slightly less state and a smaller decision tree to avoid implementation bugs. I don't know, I don't have a proposal, and I specifically used the word "wonder" and not "am engineering a better design" because I'm not. Other notes during my reading of the draft: 1. As I said, it reads like "guidance" not a specification even in the titles of the sections. Non-experimental Standards should probably be a bit more strongly worded in these areas. 2. I find the whole definition and usage of the term "unilateral" confusing. I tried to keep the overloading of the term as defined in 1.2 in my head every time I read it and completely failed. I'm sure this is entirely my fault, as I don't have replacement text for the definition that would simplify my confusion. 3. Sections 3.1 seems earlier than it should be and a touch complex. I felt suddenly in the deep end of the pool swimming toward the shallow end of section 3.2. 4. I might move the definition of E-foo up -- there are sections above it that discuss document conventions. 5. Sections of the document don't feel complete for recursive resolvers (but I didn't engineer the corner cases). Specifically, 4.6.2 and 4.6.9 feel like they're always talking about responding to the client without considering that some queries derive from recursive processing (NS/A/AAAA lookups, DS, etc). Certainly one way around this would be to clearly state that the resolver itself may be considered a client of itself (and if the draft says this, I may have missed it). Or the text could more clearly indicate that "if you get an answer AND it matches a client's query then return it (and potentially keep processing if needed as well if not done itself)". 6. I'd think for DOT multiple simultaneous sessions may be desired up to some (small) maximum in order to prevent head-of-line blocking that DOQ solves, eg. I'd have to think more of this, but maybe just the notion that unordered responses must be sufficient is ok. 7. I'm not sure the early-data discussion is needed. It seems overly specified and dives too much into the transport layer (how TLS/QUIC are specified). APIs may not even be available in some stacks to even expose that level of request to the underlying library (really: I have no idea and haven't written TLS 1.3 code). And does early DNS data need to be a full packet size? 8. 5.6.7: could just do throttling or reopen the session immediately? That's what I wrote in my notes, but I'd need to go back to re-think through it before having a discussion about what I wrote. Essentially, I'm not sure the timing for re-opening sessions is fully baked. But it's a first-pass read only. 9. 4.6.2: I think there is a downgrade attack viable here, no? If a response over Do53 comes more quickly than a response over DOT/etc... Another full read may squash some of the above, and clearly the authors should feel free to disregard any of my statements and questions if they think I'm wrong. [1]: https://b.root-servers.org/news/2023/02/28/tls.html [2]: https://ant.isi.edu/events/dinr2023/S/s43.pdf -- Wes Hardaker USC/ISI _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
