[DNSOP] Re: DNSOP[EDE] Registering a few more error codes
Shumon Huque writes: > Yes, and more specifically, to quote the RFC, they aren't allowed to > modify DNS protocol processing: True, but debugging tools may be able to use the machine readable codes as trigger points for diving into further analysis or as a hint for what other fields might be related, etc, to display to the admin/user. -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: DNSOPDNSOP[EDE] Registering a few more error codes
Stephane Bortzmeyer writes: > But there is another question: should we try to save codepoint space > by using the same EDE for many different uses (and using the extra text > to demultiplex) or should we use the fact that the registration policy > is quite open to register many codes? RFC 8914, section 5.2, does not > offer any guidance. IMHO, the answer here is "do you need a machine readable code(s) to differentiate between different actions when received?" and "is this for human debugging only and text works just fine?" Some may think that we need many code points because machine readable is rather nice to have for further debugging by tools that understand the differences, and others may think "this is only informational/debugging so we only need a text field". I lie more on the line of "having more codes with precise definitions is better". The info code is 16 bits (with some reserved for private use), so we have a *bit* [sic] of room to spare. We've used 30 out of 49152 code points, so [sarcasm] we'd better start conserving now! We've already used 0.061% of the code space![/sarcasm]. -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: DNSOP[EDE] Registering a few more error codes
Stephane Bortzmeyer writes: > In the current registry for Extended DNS Error Codes (RFC 8914), there > are codes that may be interesting to add: > > * One to say that the response was deliberately minimal (RFC 8482) > * One to say that the response comes from a local root (RFC 8806) > * One to say that the response has been tailored because of ECS (RFC > 7871) [the most useful, IMHO] Sort of akin to what everyone else has said: I think all of these look interesting and potentially(*) helpful. The real question is: what are the scenarios for each where the receiver would actually make a decision based on the code being included with the answer? For #1 - a more exact definition would be helpful. Minimal how? One thing we discovered writing the EDE draft is that it was better to have more code that clearly indicated exactly how things were being affected. IE, just saying "hey, by the way, I left something out." doesn't really let a client know what they should send more queries about. It might be better to have more specific information "Hey, you asked for ANY but I'm only responding with one type" or "Hey, you asked for NS but I'm not including all glue" or For #2: It might be useful for debugging. Having said that, I'm not sure what I would do with the information. I suppose "oh, well I don't trust you to have answered with real recent root data (even though I can validate it), so I'm going to go around you"? Fro #3: Again, what is my next step or recourse? I'm not sure here what I'd do with that new bit of information. Similarly, the parallel missing code is "I'm doing DNS load balancing so if you ask again in 5 minutes you'll get a different answer". -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: Comment on https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/
"Salz, Rich" writes: > I'm not a member of this group, but I just saw the notice about this > draft in the internet-drafts mailing list. Thanks Rich, those are all valuable comments. -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] 3 new documents related to updating the algorithm recommendations published
Greetings all, After the good discussion previously about the right levels of recommendations for deployment/usage vs implementation requirements, Warrn and I have put together three new documents that we believe find a good middle ground in all cases and look forward to further discussion. - https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/ - https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-ecc-gost/ - https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/ Cheers, and we look forward to seeing everyone in a couple of weeks at the next DNSOP meeting as well. -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: DNSOPFurther comment re algorithm life cycles
Steve Crocker writes: > Under the heading of saying what might be obvious but needs to said > anyway, there should always be at least one mainstream (phase 4) > algorithm in use. When an algorithm is moved to phaseout (phase 5), > there should already be one or more other mainstream algorithms in > use. Hi Steve, and apologies for the very late reply. I think in general we're aligned with the goals of what the content of the recommendations should generally look like within the new columns in the table. IE, there should be some sort of transition path from initial use to deprecation. A couple points: 1. In your first note you took issue with particular values in the proposed table. For this, I note that in our introduction we explicitly stated "It [this document] does not change the status of any of the algorithms listed in [RFC8624]; this is left to future documents." IE, our goal is to create the new columns in the IANA table and move the existing values from RFC8624 into the registry. THEN individual documents may wish to propose new values for the various recommendation columns. One of the primary goals, in our opinion, is to separate out the creation of the columns from the arguments associated with each algorithm. Specifically, we were worried that any time you have to update the entire table at once there will be disagreement about particular values for particular algorithms. Thus, it might be far easier to have discussions based on one algorithm at a time. 2. As to your above note, I think that's a valid point -- we should never let the table get to the state where there is not a set of appropriate MUSTs in order to get wide, stable deployment. Whether we should do that by adding a restriction in this document to tell IANA to never let this happen in an update, or whether we do that as a follow on BCP which outlines the steps you've been putting together for a while remains for discussion I think. I think either should likely suffice, but I tend to lean toward a separate BCP or something since I don't think adding overhead to the IANA processing rules is the right idea. Cheers! [PS, as a (1b) we note that we published proposed updates for the SHA1 and ECC-GOST algorithms to separate those discussions into different threads, which appears to have been somewhat helpful as there may not yet be a solid consensus about SHA1 though new values for the ECC-GOST recommendations seems more agreed to] -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: DNSOPOur reading of consensus on draft-hardaker-dnsop-rfc8624-bis, and the "must-not-algorithm" docs.
Warren Kumari writes: > Note that we have not updated the text in the repository yet as this > would be a fairly major overhaul, and we wanted to get the working > group’s opinions on the subject first. [side note: we did actually publish updates to all 3 drafts, but just not with these recommendations implemented] -- Wes Hardaker USC/ISI ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Mark Andrews writes: > If we go ahead with this these two sentences [... snip ...] That seems like a good suggestion considering the direction of the conversation. Both drafts changed accordingly, thanks for the text. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Paul Hoffman writes: > This cull-because-of-low usage thread incorrectly assumes that the DNS > is flat instead of a hierarchy. A few points: 1. I only pointed at data that people were asking for. I did not state my personal opinion. 2. I published the drafts based on desires by people to have them published. I'm at the will of the WG in the long run with respect to publishing vs not (as all document authors should be). 3. The whole discussion, IMHO, is side-stepping the real issue: if not now, then when? IE, do we never put something at MUST NOT? Is there a usage threshold? Is it "must be zero"? Is it "known to be broken and everyone must have a flag day instead of a slower process"? These are not easy questions, and there does seem to be many different opinions. RedHat led the pack(ish), and maybe Paul and others will be the tail end at some very late value. There is no right or wrong, and the line of people are likely to spread out along the timeline. And what makes the situation worse is not whether or not "we" want the timeline to have a fixed transition point, but the roll out and adoption and abandoning of older software in the DNS(SEC) landscape takes a really really long time. So the trade off of when to say "stop using this" vs "all software has already stopped using it" has a really really long gap in the middle. There is no perfect. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Paul Wouters writes: > Perhaps Viktor can share his updated numbers with us. Viktor's daily scanning numbers are host on our USC/ISI server at: https://stats.dnssec-tools.org/#/?dnssec_param_tab=0 Click on "DNSSEC Parameter Trends" followed by "KSK algorithm", etc. KSK usage (click on the "domain count" column to get the sorting to match this): 13 11145536 8 11065103 10 205662 14 144076 7 119678 (rsash1-nsec3-sha1) 5 19750 (rsasha1) 15 13497 The SHA1 counts are 2 orders of magnitude lower than the EC and SHA256 based algorithms. To see trends, you can click on labels on the graph to remove them from the graph to zoom in on the nearly flat lines at the bottom. ZSK counts are similar (oddly 7 is slightly higher and 5 is slightly lower). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments on draft-hardaker-dnsop-must-not-ecc-gost-00
S Moonesamy writes: > I took a quick look at draft-hardaker-dnsop-must-not-ecc-gost-00. > The Introduction Section states that the security of the ECC-GOST > algorithm has been slowly diminishing over time as various forms of > attacks have weakened its cryptographic underpinning. There isn't any > information in the draft about those various forms of attacks. Is that > like someone the audience (of the draft) is expected to know after > reading the eight RFCs which are referenced by the draft? :-) We could certainly omit the text that says it's diminishing over time, but I think it's widely accepted to be true but all the normative references we'd have to point at are a bit outside the scope of our normal referencing. We could probably point to some informational documentation more easily, and if the WG wants to do that I'm all for it. We should provide some reason why we're deprecating it, and there does seem to be consensus within the DNS portion of the IETF that we should. Or put it differently, if the WG doesn't think there is consensus to do so then the draft shouldn't be published, but if "we" (royal) do then we should publish it. > Appendix C has a reference to draft-hardaker-dnsop-must-not-sha1 > instead of this draft. Yep, noted by a few people. Fixed in future versions, thanks. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-hardaker-dnsop-rfc8624-bis in state "Candidate for WG Adoption"
Bob Harold writes: > I support this. Hi Bob, Thanks for the support and the bugs. Inline below: > It sounds like future updates will be separate RFC documents, so it seems odd > to say > 'this document' in 1.3. Perhaps "future documents" ? (I assume this text > was just > copied from the previous version.) Good point, thanks. Updated. > 1.3. Updating Algorithm Requirement Levels > ... >This document attempts to identify and introduce those algorithms for >future mandatory-to-implement status. ... >Published algorithms are continuously subjected to >cryptographic attack and may become too weak, or even be completely >broken, before this document is updated. I changed this significantly to: By the time a DNSSEC cryptographic algorithm is made mandatory-to-implement, it should already be available in most implementations. This document defines an IANA registration modification to allow future documents to specify the implementation recommendations for each algorithm as the recommendation status of each DNSSEC cryptographic algorithm is expected to change over time. For example, there is no guarantee that newly introduced algorithms will become mandatory to implement in the future. Likewise, published algorithms are continuously subjected to cryptographic attack and may become too weak, or even be completely broken, and will require deprecation in the future. > Typographical cleanup: > > In "3. DNS System Algorithm Numbers Column Values", > what was "table 1" should probably be "table 2" both in the text and > under the table. Yep, fixed. Thanks. > The table heading two rows should probably be a single row? With > "Recommended for DNSSEC Signing" in a single cell, and "Recommended > for DNSSEC Validation" in a single cell. And row 10 in the table > appears to be split. "NOT RECOMMENDED" should be a single cell. Well, this is an artifact of markdown conversion because they aren't separate cells -- they're one cell with dividers in markdown. I'll work on fixing that, thanks. (insert mandatory sigh here) > In "4. DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest > Algorithms Column Values" > > It should be "table 3" in the text and under the table. Fixed > And the header for each page has a placeholder "title" instead of the > actual title. Yep, now: title: "DNSSEC Cryptographic Algorithm Recommendation Update Process" abbrev: "DNSSEC Algorithms Update Process" -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RFC8624-bis proposal update and two more documents
Warren and I have just published long promised documents. The first updates RFC8624 to move all recommendations to the DNSSEC registries, similar to how TLS does. The next two request updates to said registries for deprecating SHA-1 and ECC-GOST, which we believe the community wishes to happen. - draft-hardaker-dnsop-rfc8624-bis - draft-hardaker-dnsop-must-not-sha1 - draft-hardaker-dnsop-must-not-ecc-gost (These are early drafts so there are certainly things to discuss about them. We look forward to those discussions.) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] CFP for DINR 2024 virtual workshop, Apr. 4, 2024, for early DNS research
We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions - 2024" (DINR-2024). We will be holding this workshop virtually over Zoom on Thursday 2024-04-04 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). This year, we have a particular focus on privacy and security of the DNS both now and in the future. For example, how has DNS-over-TLS and HTTPS or QUIC changed privacy for their users? Or operations for providers? However, we continue to welcome all DNS-related topics on infrastructure, tools, and any early DNS and general name space related work as well as any important updates about previous work. If you have work in these areas to share, or you want to hear about what the community is doing, we'd love to have you join us for DINR-2024. Like previous years, we're planning for a very interactive day of short talks followed by longer discussions. We are soliciting short abstracts (suggested 1 page text + 1 page references) from people who are interested presenting at the workshop. Abstracts are due soon on 2024-03-04, but as a reminder they need not be lengthy. 1-page maximum contributions are preferred. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI), with Allison Mankin (Salesforce) and Moritz Müller (SIDN Labs) on the Technical Program Committee. If you wish to attend but not present, please submit a paragraph stating you wish to attend only and provide a brief background about your involvement with the DNS and identification. For details about DINR2024, see https://ant.isi.edu/events/dinr2024/ . (For information about DINR in prior years, see https://ant.isi.edu/events/ .) Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2024sub . -John and Wes on behalf of the DINR2024 TPC -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
Edward Lewis writes: > # 1.6. Facilities > # > #The DELEG record is extensible in such a way that future innovations > #in the domain name system, such as new methods of secure transport, > #message encoding, error reporting, etc, does not depend on a re- > #design of the DNS. > > But the DELEG resource record enables redesigning (portions or all of) > the DNS. I think the point is that DELEG allows the DNS namespace to > continue to be published while there are transitions in the DNS > publication protocol (motivated by improving the state of operations). Put another way: yes, DELEG records are extensible. Just like the DNS is with new RRTYPEs. But we've proven already (and DELEG is an example) that trying to assume adding a new RRTYPE or DELEG flag may require fundamental changes in processing regardless of how that new flag is encoded. Extensibility != easy deployability. It *can* but it shouldn't be assumed that all future simple on the wire changes of any type won't require major code overhauls to handle it. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
IESG Secretary writes: > The Domain Name System Operations (dnsop) WG will hold a virtual > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > (17:00 to 18:00 UTC). I'm sadly very day-job conflicted with this slot, but greatly look forward to watching the replay afterward (I may try to sneak an earpiece into my head but it's unlikely I can pull that off). I'll note that if we're going to go down the road of such a major change to parent/child/resolver interactions, it is highly important we get opinions and viewpoints from all segments of the DNS industries to ensure this is widely deployable. Having said that, if I can't keep my own zones in sync properly with my registry's advertised data: it's time to do something about the problem. [yes I recognize this is not an adequate summary of the problem space, but it's a part]. Whether this is the right solution or not will depend on feedback from many voices. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane
Ben Schwartz writes: > I wanted to remind DNSOP to take another look at > draft-ietf-dnsop-svcb-dane [1], which is intended as a straightforward > clarification of how DANE interacts with SVCB/HTTPS records (and > QUIC/HTTP/3). I don't think this document is controversial, and I'd > like to proceed to WGLC soon. A few comments: 1. the MUST NOT in the first paragraph in 5.2 really feels like it should be a SHOULD NOT. Though its not wise, there could be scenarios where someone really wants to do it and if they feel it's operationally possible then they should be allowed to. [I had a really hard time writing this, as I think you're right about the importance, but we do try to opt for SHOULD NOTs unless it always breaks something] 2. in the security considerations, the first sentence in the second paragraph seems like it should have a solid requirement in it. Maybe "The SVCB and associated TLSA records MUST be validated by DNSSEC." And this is one of those cases where the MUST feels right as it significantly degrades the security of the protocol if only a SHOULD is used. As such, I'd drop the rest of the paragraph. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPWorking Group Last call for draft-ietf-dnsop-dns-error-reporting
Roy Arends writes: > That, IMHO is already captured by the last paragraph. I did not > explicitly write a recipe of how to do that, and which servers could > be used for that :-). Could you suggest text to improve the last > paragraph without naming services? Erg. I hate it when I have to come up with text :-P How about replacing the last sentence of security considerations with: This method can be abused by intentionally deploying broken zones with agent domains that are delegated to victims. This is particularly effective when DNS requests that trigger error messages are sent through open resolvers [RFC8499] or widely distributed network monitoring systems that perform distributed queries from around the globe. Implementations SHOULD rate-limit outgoing error messages to a recipient to no more than 1 a minute. [reword as you will, of course... the last sentence subject to the largest debate] -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPCall for Adoption: Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Tim Wicinski writes: > This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency I think this is important work and needs to get processed by DNSOP, and as such I support this document as the starting point for the work and encourage its adoption. Having said that, I'm not entirely sure that its exact concepts at the moment are what should be published in the long run (more below). For lame delegations, I think discussion is needed further. It's unclear from the draft at the moment (and I think it needs to be very clear) about what to do with servers that are lame. It discusses whether or not CDS/CDNSKEY/CSYNC are supposed to do when the server is unresponsive, but not with respect to other errors or situations and I think some clarity would be helpful here. I think it's important that we deal with the multi-signer case, and that point is very clear (and correct). But we also do need to be able, as a child, to update a parent's records when a nameserver has gone offline or stopped responding appropriately. This is very different than one NS taking over -- IE, I agree that this is the principle thing to defend against. But we also need to be able to efficiently recover from operational situations. Nits as long as I was reading it with a red pen: - Introduction: CSYNC updates both NS *and glue* records - Lame delegations: "on the other hand, if the delegation is not protected by DNSSEC," -- I don't understand this because all three record types require DNSSEC to be in place and valid for any of the records to work. No changes should ever be permitted without both present and valid signatures. Maybe I'm misunderstanding the paragraph though. - Section 3 is likely where service failure / error conditions need to be discussed more fully (IMHO). - 3.2 CSYNC: There are a few things to check here and all the servers should be consistent with all the records for changes to be made: the CSYNC record itself, the NS records and the glue records. (or since CSYNC is generic: the CSYNC record and any records it is referring to). IE, the CSYNC records could be equal but the NS records need to be checked for equivalence at each server too. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPWorking Group Last call for draft-ietf-dnsop-dns-error-reporting
Benno Overeinder writes: > This starts a Working Group Last Call for: > draft-ietf-dnsop-dns-error-reporting. Overall: I support the publication of this document and believe it is a good addition to the DNS specifications. Some suggestions: - section 1: "reported via social media" -> "report via E-Mail or social media" -- anyone subscribed to dns-operations and various *og lists will know that a lot of errors are reported to operational communities over email. - Terminology: Why is a reporting resolver listed as validating here? From what I can tell from the rest of the document, this should be a more generic reporting mechanism even if the examples are DNSSEC related. The EDE document has many errors that have nothing to do with DNSSEC (filtering being one example). - Terminology: Report Query's last sentence is hard to read. Maybe "The content of the error report is encoded in the QNAME of a DNS request to the reporting agent." - TBD: Terminology: Monitoring agent: I'm not sure that the monitoring agent has to respond or not? - Terminology: Agent Domain isn't really describing what the agent domain actually is used for, but rather just where it's encoded. How about "A domain name which is returned in the DNS Error Reporting EDNS0 option that indicates where DNS resolvers can send error reports." - section 5: option-code "indicates error reporting support is TBD". I suggest it would more clearly understood if it included a reference to the fact it's an EDNS0 code: "an EDNS0 code that is used in an EDNS0 option to indicate support for error reporting. The name for this EDNS0 option code is Report-Channel" - 6.1 reporting resolver specification: "The EDNS0 report channel option MUST NOT be included in queries" -- above you label it as "Report-Channel" and I suggest you be consistent with the usage everywhere (I didn't check if "report channel" in lower case with a space exists elsewhere too) - 6.2: I'm not sure the reason behind this requirement. Why would it matter if more than one agent supported *receiving* reports? I think the real requirement should be that authoritative servers SHOULD only send a single reporting agent to a client and thus only a single Reporting Channel EDNS0 option. (I could even argue this should be a MUST.) But on the server side (either the authoritative server or the report-receiving authoritative server) I don't see the point in putting this restriction on them. - security considerations: In the last paragraph I'd mention that there is a concern that large measurement query networks (RIPE atlas) or bot-networks could misuse this and likely achieve an amplification attack against a name put in the reporting option. I actually wonder if it would be good to put in a time-bound rate limit to the number of error reports that should be sent anywhere as I have concerns that this could be too easily misused and caching may not be a completely sufficient mitigation. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] rfc8499bis: lame
Katherine Chen writes: > The word "lame" is also problematic in the US: As someone who grew up in the US and was frequently called "lame" during jr-high / middle-school age even though I didn't have a hurt leg, I have to agree: it's a problem in the US too. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rfc8499bis: lame
Paul Wouters writes: > That was one of my suggestions, don't define it or declare it obsolete. > It will ofcourse take time for people to stop using it. There were a number of us in favor of this option, I think. But the consensus was certainly not there to stop using the term. Maybe the tide is shifting, as it seems like more are in favor of defining new terms now than the previous discussion round. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] New addresses for b.root-servers.net on 2023-11-27
USC/ISI is renumbering both its IPv4 and IPv6 addresses for b.root-servers.net on 2023-11-27. Our new IPv4 address will be 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b. USC/ISI will continue to support root service over our current IPv4 and IPv6 addresses for at least one year (until 2024-11-27) in order to provide a stable transition period while new root hints files are distributed in software and operating system packages. We are renumbering to increase the resilience of the Root Servers System by further diversifying the number of Regional Internet Registries (RIRs) that have allocated IP addresses to Root Server Operators. Our addresses will be the first in the Root Server System to have been allocated by LACNIC and our routes will be verifiable through LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor Location (TAL). We thank LACNIC for helping make this renumbering possible, and ARIN for supporting our prior addressing assignments. The LACNIC announcement, with English, Spanish and Portuguese translations, can be found on their website here: https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al-servidor-raiz-de-usc_isi Please direct any comments or questions to b-poc isi.edu. Regards, The USC/ISI root operations team P.S. Apologies to anyone receiving multiple copies of this announcement. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
Paul Vixie writes: > > There I fixed it for you: > > that's a meme, right? Yes, it was a joke. Apologies if it offended you in any way. My point was to indicate that: 1. There are multiple (mis)understandings of what a lame delegation is (regardless of whether or not the original terminology was more precise and drift has happened) 2. There are in fact multiple underlying issues that could be better documented in error messages to better explain to operators exactly what problems are being seen. This may require multiple terms to achieve a better set of explanations. Similar to how EDE has extended the reasons why a SERVFAIL (or other error codes) may have been encountered. > if you want to fix it I've mentioned before that I think it would be better to have multiple terms that defined more precise errors of exactly what was going wrong from the point of view of the error-generator. I typically don't rehash my past statements unless I have something to add [and I don't - my original statements still stand]. The consensus seemed to be at the time "it's not broken, so we shouldn't fix it". -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
Paul Vixie writes: > if we need more terms let's invent. but this term has established meaning. There I fixed it for you: If we need more terms let's invent. But this term has established meaning*s*. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Meaning of lame delegation
Paul Hoffman writes: > The term "lame delegation" is defined in two RFCs, which are > referenced in the terminology draft. This has caused the term to be > commonly used. I'm not saying that some people don't understand it. It's just a weird english choice that we're sticking with because of history. I think if it had been re-named "broken delegation" and *that* was commonly used there would be less confusion, even though it's only a single word change. Operators do not go looking into RFCs when their log messages spit out some strange wording choices. But... I've said my voice, so feel free to reply but I tend not to follow up unless I have new things to add (and I doubt I will further). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Meaning of lame delegation
Warren Kumari writes: > Yup, lame delegation and lame server are still in very common use — That doesn't mean it should be. > and (IMO) it's usually clear from context what is being > communicated. Having been historically (and likely futurely) confused by the term, I disagree. It is not clear at all to anyone new to the DNS what "lame" means I suspect we could switch to better terminology. Will it disappear tomorrow? No, of course not. But if servers start spitting out different log messages and we generally use more accurate terminology in our conversations then I believe understandably will go up from where it is now. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPMeaning of lame delegation
Havard Eidnes writes: > If I'm not terribly mistaken, EDE is for communicating recursive > lookup or validation errors between a recursor / validator and a > stub resolver Actually, no. We kept it very deliberate and generic so it could be used in any context. The requirement, though, is that it only conveys a code between the client of any type and the server of any type. It shouldn't be a code that is proxied from a more distant server through something else (IE, copy/paste of a code is prohibited) because a client must have a concept of what server is actually generating the error code and this isn't understandable when proxied. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPMeaning of lame delegation
"Wessels, Duane" writes:
> We welcome the working group's thoughts whether "lame delegation"
> encompasses these three possibilities.
FYI, when working on the EDE draft [RFC8914] we discussed lame
delegations some and actually did not document a particular error code
related to it, as the meaning both uses improperly precise terminology
("lame" is not really a useful adjective in this situation) and because
of the multiple reasons why an authoritative server may not be
responding, as you indicated.
I was originally thinking of listing the various parts of section 4 in
RFC8914 that were directly tied to the lame discussion, but I'm not sure
I'd get it right. So instead I invite you to look at section 4 of
RFC8914 and see if there is any of the situations that SSAC is concerned
about that are not covered by one of those codes that are designed to be
more specific about the actual nature of the problem being observed by a
recursive resolver.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPRFC 8914 EDE code for filtered rrtype
Petr Menšík writes: > I have made a proposal to mark all filtered out queries with EDE > code Filtered (17). However codes 15-18 all describe themselves as > per-domain rules. I agree that none of these look appropriate based on re-reading the text. I actually think your desire to filter by qtypes is not anywhere in the purpose of the original list. Thus... you need to write a draft with a new EDE code allocated I think. > Or maybe wording of those codes should not suggest they operate on > domains level only? I'd definitely think that is not right. The point of EDE is to separate out the different related problems, not to combine them. So a new code is really needed. If you want to use one now, I'd suggest 21 - not supported my be the closest as you're delicately not supporting some aspect of DNS (a qtype [*]). [*] which, interestingly, reads just the same as ( qtype) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt
Jim Reid writes: > Depends on the definition of DNS traffic Ted. DNS-OARC has many TB of > pcaps and query logs from the DITL project. Whether that data could be > good enough to meaningfully measure the incidence of QDCOUNT>1 in the > real world is anyone’s guess. If it helps, looking at *only* the qdcount field for all traffic arriving at b.root-servers.net yesterday for any packets where qdcount was greater than 1 was precisely zero. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] reminder: dinr2023 submissions due soon
For those doing DNS research and wish to attend our DINR2023 virtual workshop, a reminder that submissions are due this week. We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions - 2023" (DINR-2023). We will be holding this workshop virtually over Zoom on Wednesday 2023-02-22 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). This year, we have a particular focus on making naming data usable: labeling data, use of machine learning over labeled, data, and how anonymization interacts with analysis. However, we continue to welcome all DNS-related topics on infrastructure, tools, and any early DNS and general name space related work. If you have work in these areas to share, or you want to hear about what the community is doing, we'd love to have you join us for DINR-2023. Like previous years, we're planning for a very interactive day of short talks followed by longer discussions. We are soliciting short abstracts (suggested 1 page text + 1 page references) from people who are interested presenting at the workshop. Abstracts are due soon after the start of the new year (2023-01-18), but as a reminder they need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI), with Goeff Huston (APNIC) and Giovane Moura (SIDN Labs) on the Technical Program Committee. For details about DINR2023, see https://ant.isi.edu/events/dinr2023/ . (For information about prior versions DINR2021 and DINR2020, see https://ant.isi.edu/events/ .) In addition, we will have a short tutorial about the DIINER experimental produced datasets and our DNS testbed on 2022-02-23. For details about the tutorial, see https://ant.isi.edu/events/dinr2023#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2023sub . -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] CFP for DINR 2023 virtual workshop, Feb. 22 2023, for early DNS research
We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions - 2023" (DINR-2023). We will be holding this workshop virtually over Zoom on Wednesday 2023-02-22 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). This year, we have a particular focus on making naming data usable: labeling data, use of machine learning over labeled, data, and how anonymization interacts with analysis. However, we continue to welcome all DNS-related topics on infrastructure, tools, and any early DNS and general name space related work. If you have work in these areas to share, or you want to hear about what the community is doing, we'd love to have you join us for DINR-2023. Like previous years, we're planning for a very interactive day of short talks followed by longer discussions. We are soliciting short abstracts (suggested 1 page text + 1 page references) from people who are interested presenting at the workshop. Abstracts are due soon after the start of the new year (2023-01-18), but as a reminder they need not be lengthy. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI), with Goeff Huston (APNIC) and Giovane Moura (SIDN Labs) on the Technical Program Committee. For details about DINR2023, see https://ant.isi.edu/events/dinr2023/ . (For information about prior versions DINR2021 and DINR2020, see https://ant.isi.edu/events/ .) In addition, we will have a short tutorial about the DIINER experimental produced datasets and our DNS testbed on 2022-02-23. For details about the tutorial, see https://ant.isi.edu/events/dinr2023#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2023sub . -John and Wes -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
"libor.peltan" writes: > On the other hand, I agree that an analysis of how heavily the Root > Server could potentially be impacted by stray .alt queries would be > beneficial for deciding if we need to implement a defense and how. But > I doubt this is possible to estimate. Well, we do have some past examples of other strange things to call upon. There was some oddness with increase queries during the DNSKEY roll [1]. Then there was the chromium random DNS query string usage, which I first spoke about at DNS-OARC in 2019 [2] and VeriSign later wrote about in 2020 [3]. My guess is that queries for .alt would be less than the chromium "feature", since negative answers for .alt would be cached by resolvers at least unlike the random unique strings from Chromium. Footnotes: [1] http://doi.acm.org/10.1145/3355369.3355570 [2] https://youtu.be/sh9Bbk_1bMQ?t=1365 [3] https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/ -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
David Conrad writes: > whether the IETF “reserving” a TLD is intruding on ICANN’s territory. > > After WG LC, I propose that the WG chairs, ADs, IAB, and ICANN liaison > discuss this. My current expectation is that we probably will send ICANN > a > liaison to politely let them know what we are doing, so that they have the > opportunity to comment, and we would consider any feedback that they give, > returning the document back to the WG, if needed. > > I guess that’s marginally better than what the IETF did with RFC 6762 (i.e., > publish the RFC ‘reserving’ a TLD then, a year and a half later, issue the > liaison statement to invite discussion). The reluctance to ask the question > still > seems silly to me, particularly if one wishes to maintain good relations, but > this is clearly deep into the political sphere so I won’t bother arguing > further. Hi David, The IAB discussed a while back about "when" to send a statement to the ICANN board about this issue. The decision was that if the WG didn't have consensus yet (we have a bit more of one now than then), it sure seem appropriate to send ICANN a note with a "maybe we might if we can ever come to internal agreement". In other words, it's just wasting their time if we haven't even decided something is a good idea. So, the decision made at the time was: once the WG has concluded that something is a good idea (a draft passes WG last call), *then* it seems like the right time to send a message to ICANN about our plans. That being said, the IAB is also aware of this issue and will be further discussing it in the next few weeks. If you wish to make arguments about why the previous decision about whether the question should be asked immediately, and what the nature of that question should be: I'm all ears and will pass it on (at least in aggregated consensus form) during future IAB discussions. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Stephen Farrell writes: > FWIW I don't understand why people seem so down on the idea > of enabling other people to experiment with other ways of > playing with names. Actually, it seems to me that much of the argument has turned away from "this is a bad idea" to simply "should we have a registry and how will this work?" Based on the last week of mail, the general concept of "we need a carve-out" (to use Paul's terminology) seems generally agreed upon. It's just the details that aren't agreed to yet. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Ben Schwartz writes: > Conversely, I think an alternate URI-scheme is actually _more_ likely to have > good compatibility with non-alt-aware software. First, for the record: I think a URI approach is a far better solution. And I'm trying to guess at the motivations of others not using it (which I probably shouldn't do; but I will point out that all the other systems aren't proposing alternate-URI schemes but I'm sure at least some of them have thought about it. If you're one of those, please speak up!) I will note that of all my binaries in /usr/bin on my random linux system, 199 of them have references to either gethostbyname or getaddrinfo. It may be that you could mess with the base C library that implements those to accept a URI instead (yay), but I think it may be harder to fix all the UIs on top of it that may be doing regexp matches to ensure the user input is valid before accepting a submit button. Maybe. Maybe not. It feels like a hope, not an assured solution. Even though it's the *right* thing to do. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Ben Schwartz writes: > Rather than placing "alt" in the TLD position, I think it might be better as a > scheme modifier: https+alt://... This is a common pattern for modifications > to > URI schemes (c.f. git+ssh://), and informs the software that this URI is > special > without overloading the DNS namespace. I suspect many of us would agree that's the best ideal way forward, except that the proponents of the alternate names want their names to be as DNS-like as possible so it works with *all* applications. All new ones may support extensions and URIs, etc. I'm not sure telnet, nntp readers, etc do/will. I don't even know how to enumerate all the places where a domain name is expected (endless GUIs) that don't have an appropriate name space selector option. Certainly a "too bad for you" approach for situations like that, but I suspect that's going against what the alternate name space proponents want: minimal upgrades to existing software [right or wrong as that may be -- no judgment here]. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Timothy Mcsweeney writes: > > Sadly, we almost > > need two .alt name spaces: one which is explicitly > > not-registry-controlled, and one which is. > > > > Who is 'we' in the above sentence? There are two camps of people that want to play in the alternate naming space: 1. Those that want to figure out a way to inter-operate such that conflicts don't occur and that an end-user can likely get the answer that they're looking for, even with multiple naming systems in place. How this happens, and where the magic flag occurs that says "you're leaving the DNS naming system but still using a DNS like name" is left to be decided, including whether one or multiple boundaries include a 1. "but you can now consult this alternate naming system registration table" or 2. "beyond here you're on your own" [not intending to be negative here]. 2. Those that deliberately want to collide because the nature of their solution may be to "replace" the DNS because they detest centralization based solutions, or think theirs is simply better, or The "we" was referring to 1. The definition and examples could, of course, be a lot longer and more refined. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Joe Abley writes: > > Normally, a registry is created when it will help the operation of > > the protocol. The problem here is that there's an _anti_-protocol, > > and therefore it's mystifying to me how a registry helps anything, > > since there is no way to know whether a registry will actually help > > or in some cases even hurt. > > Yes. This. To put this another way: the proponents of the currently active non-DNS naming systems are creating these systems with an active desire to avoid a centralized form of control over the name space they're creating. And by having a registry, it would re-insert some level of control that they're explicitly fighting against. I don't think Eliot is wrong when he said: > > > As a matter of practicality, a registry surely will be form. Any registry that the current designers would be most happy with would also be not a centralized registry. Who knows, maybe it'll be "last edit on wikipedia" or "king of the hill" or "will get put as a default in the GNS" (which, ironically, becomes a central point of control if no one deviates from it). The point is: if these systems want a complete decentralized space to play in and know the risks of toe-stepping, then that's fine. Now, the problem we'll run into is along comes a new name space system that wants to be more centrally controlled, but is still not the DNS. Clearly, .alt won't be the perfect solution for them. And they'd prefer something like .reg.alt where conflict doesn't occur. Sadly, we almost need two .alt name spaces: one which is explicitly not-registry-controlled, and one which is. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible alt-tld last call?
Warren Kumari writes: > 1: as we've already seen, nothing stops people from just using whatever names > they want[0], and so there is no guarantee that registry would be complete and > correct. So the interesting side-point is that what happens with people that don't want to go through the process of registering? IE, if the burden is high or they're simply lazy, they'll still end up squatting. So we need an alt.alt that isn't registered at all? Do we make the burden so low that it attracts hopefully everyone? Do we not have a registry so this problem goes away? ... -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible alt-tld last call?
Martin Schanzenbach writes: > Wouldn't such a WG need the .alt as a prerequisite to any actual work or > at least have .alt as its first work item? Actually, that's only one solution. It's the easiest and hence the reason it's being preferred. The probably *right* solution is to fix all the documents specifying implementation with respect to naming that assumes the DNS is the only system (URLs) [1], and all the APIs that make use of it (getaddrinfo). The list of RFCs to update to allow namespace selection is far from short. [1] note that this statement is both right and wrong in many ways. I'm avoiding the more complex aspects. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Editorial Errata Reported] RFC9276 (7104)
Viktor Dukhovni writes: > > There is a typo, "opt-opt" should be "opt-out". > > > Thanks, this correction is valid. Indeed it should have been > "opt-out". Concur! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Paul Wouters writes: > I drop my objection to changing SHA1 status :) I win I win! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPAuthorship - was: Re: [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Michael StJohns writes: > One of the downsides to leaving them on the author list is the need to > involve them in the AUTH48 process. That can be painful if you're not > actually actively working the document even if you're the source of > much of the text. Of course I'll work it out with them about whether they want to be an author in the first place. Paul has already agreed to be left. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt
Paul Wouters writes: > first read of rfcdiff So I actually took the draft from the github archive from both of you, not from the real 8624 xml (because I couldn't find it -- though I know it exists). > > guidance for DNSSEC. This document obsoletes . > > - no targets allowed in the abstract :) But you guys had one in the original draft! > - You removed RFC8174 from the 2119 text for no good reason :) Fixed (again, copied from source) > - SHA1 changed for validation from MUST to SHOULD NOT. This is the > discussion item for the WG :) Yep. It's a discussion place holder > - GOST to MUST NOT, ok but could add GOST 2012 as per > draft-ietf-dnsop-rfc5933-bis Yep, I needed to find the reference for that. So thanks. > - You changed NOT RECOMMENDED terminology to SHOULD NOT (I think I > originally had that and Ondrey / the WG preferred NOT RECOMMENDED). > Either works for me. I actually had NOT RECOMMENDED originally, but people in the WG were suggesting SHOULD NOT in the comments so far so I switched it. I'm fine with either. > - NIT: The SHA-256 is RECOMMENDED [for the] DS and CDS algorithm[s]. All fixed. [and invited you to the github repo too] -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt
Because it's also time... Start of forwarded message From: internet-dra...@ietf.org To: "Ondrej Sury" , "Paul Wouters" , "Wes Hardaker" Subject: New Version Notification for draft-hardaker-dnsop-rfc8624-bis-00.txt Date: Mon, 15 Aug 2022 09:17:53 -0700 A new version of I-D, draft-hardaker-dnsop-rfc8624-bis-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Name: draft-hardaker-dnsop-rfc8624-bis Revision: 00 Title: Algorithm Implementation Requirements and Usage Guidance for DNSSEC Document date: 2022-08-15 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/archive/id/draft-hardaker-dnsop-rfc8624-bis-00.txt Status: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-rfc8624-bis/ Htmlized: https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-rfc8624-bis Abstract: The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of non- existence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes [RFC6944]. The IETF Secretariat End of forwarded message ---- -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Paul Wouters writes: > This is why I also think 8624bis is better than a stand-alone document, > as it takes into account security effects, market deployment, and > trying to push the deployments to where we want it to go, instead of just > issuing a document the current deployments have no choice but to > ignore. So, I took the liberty of stealing much text (as all good authors do). I submitted a draft-hardaker-dnsop-rfc8624-bis leaving both you and Ondrej as co-authors (because it would be extremely rude not to), and I'm sure we can come to agreement about what the expected table entries and text should look like. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Paul Wouters writes: > If only we had thoughts about this before, hey look RFC 8624. Why not > do a bis of that one ? (Yes I have thought about it as author, but I > don’t agree we can/should kill sha1 yet on the validation path) That's a possibility too, but then I'd have to fight the authors about whether to kill sha1 or not :-P -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Roy Arends writes: > What is missing is how validators/validating resolvers should behave > when presented with SHA1. Yep; see the response to Jim. [the draft was a starting place, of course; I'm sure there will be more text needed. "send text" is always an adequate thing to do] -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1
Jim Reid writes:
> Wes, I'm all for killing SHA1. Though the mechanism might need a
> rethink. We probably should have a simpler way to add/remove DNSSEC
> crypto algorithms. IIRC Paul Hoffman explained the problem a year or
> so ago when new code points were needed for the latest GOST
> algorithms: something about that could only be done with the overkill
> of a Standards Track RFC. Maybe that could get fixed and SHA1 could be
> its first victim?
I think it would take a while to fix the process, and this draft was
triggered by the discussion in the dns-operations mailing list which
puts it at a slightly higher priority. So though your suggestion is
likely something the WG should consider, I'd argue the fixing of that
shouldn't hold up us deprecating SHA-1. IMHO of course.
> As for the I-D, I think it should also say validating resolvers MUST
> NOT use SHA1-flavoured RRtypes for validation. ie Give SHA1 two shots
> to the head, just to be sure. :-)
Something like:
# Deprecating SHA-1 algorithms in DNSSEC
The SHA-1 {{RFC3685}} algorithm MUST NOT be used when creating DS records.
Validating resolvers MUST treat DS records as insecure. If no other DS
records of accepted cryptographic algorithms are available, the DNS
records below the delegation point MUST be treated as insecure.
The RSASHA1 {{RFC4034}}, DSA-NSEC3-SHA1 {{RFC5155}}, and
RSASHA1-NSEC3-SHA1 {{RFC5155}} algorithms MUST NOT be used when
creating DNSKEY and RRSIG records. Validating resolvers MUST treat
RRSIG records created from DNSKEY records using these algorithms as
insecure. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver MUST consider the
associated resource records as Bogus.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt
Because it's time... Start of forwarded message From: internet-dra...@ietf.org To: "Wes Hardaker" Subject: New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt Date: Fri, 12 Aug 2022 08:48:21 -0700 A new version of I-D, draft-hardaker-dnsop-must-not-sha1-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Name: draft-hardaker-dnsop-must-not-sha1 Revision: 00 Title: Remove SHA-1 from active use within DNSSEC Document date: 2022-08-12 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/archive/id/draft-hardaker-dnsop-must-not-sha1-00.txt Status: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-must-not-sha1/ Htmlized: https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-must-not-sha1 Abstract: This document retires the use of SHA-1 within DNSSEC The IETF Secretariat End of forwarded message -------- -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] signing parent-side NS
Mats Dufberg writes: > Parent is not authoritative of the NS in the delegation. The same with > any glue address records on or below the delegation point. The parent > does not sign non-authoritative records. The odd thing about this situation, as the above well states the history: the parent isn't authoritative for the NS and glue, but yet it still exists in their zone. So it's this hybrid case where they publish data, and seem authoritative to the DNS client asking for where to talk to the parent's child, but it's the client's fault if the parent is serving incorrect data (IE, the child/parent are out of (c)sync). The history basically says "we believe that there is only one authoritative source of this data", but the reality says "there may be only one source of authoritative data, but multiple publishers may distribute copies of it that may or may not be correct". In the end, there are two sources of authority: - who creates the records - who is distributing the records IMHO, it would be helpful if the distributors would stand by their statements of publication, even if they didn't actually create the records. I don't think signing the distributed records would change the behavior of whether or not clients cached them or whether clients believed who was authoritative (IE, I don't think resolvers are making caching decisions based on whether something was signed or not). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPCall for Adoption: Using Service Bindings with DANE
Tim Wicinski writes: > Please also indicate if you are willing to contribute text, review, > etc. I think this is an import draft and will support it by reviewing it and suggesting text (I already have some minor things I'll likely bring up). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPCall for Adoption: Negative Caching of DNS Resolution Failures
Tim Wicinski writes: > This starts a Call for Adoption for Negative Caching of DNS Resolution > Failures Yep, definitely needed and will support by reviewing. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Petr Špaček writes: > Sorry for being so late on this ... Thanks Petr! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-10.txt
This version only fixes rendering issues. Tim/Paul: I think this version should resolve all comments/etc from the IESG. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-09.txt
Vladimír Čunát writes: > The long addition in "Flags" section broke the sentence into which it > was inserted (by mistake?). I also can't see that change in the > newest git. turned out to be a mishandling of trailing line whitespace by the md->xml tool. Fixing now and will be ok in -10. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)
Paul Wouters writes: > I didn’t see in this email whether an Update: clause will be added ? There will be an update clause, yes. Current headers: Network Working GroupW. Hardaker Internet-Draft USC/ISI Updates: 5155 (if approved) V. Dukhovni Intended status: Best Current Practice Bloomberg, L.P. Expires: 13 November 202212 May 2022 -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Paul Wouters' Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)
Paul Wouters via Datatracker writes:
Hi Paul,
Sorry for the delay in getting back to you, but thank you for the
comprehensive review.
> Good document, nice to see operations feedback back into the IETF via a new
> BCP.
>
> comments:
>
> The algorithm field is not discussed by this document.
>
> Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are
> discussed?
Good idea. Paragraph changed to:
The algorithm field is not discussed by this document. Readers are
encouraged to read {{?RFC8624}} for guidance about DNSSEC algorithm
usage.
> The NSEC3PARAM flags field currently contains no flags, but
> individual NSEC3 records contain the "Opt-Out" flag
>
> This reads a little odd. Because the IANA NSEC3param registry lists 1 flat,
> the
> opt-out flag:
>
> https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1
>
> Maybe a sentence more clearly stating there is currently only one flag defined
> and that is opt-out and then discuss it.
I think by "flat" you really mean "reserved"?
How about this:
The NSEC3PARAM flags field currently contains only reserved and
unassigned flags. Individual NSEC3 records, however, contain the
"Opt-Out" flag {{RFC5155}}, which specifies whether that NSEC3 record
provides proof of non-existence.
> are encouraged to use a flags value of 0 (zero)
>
> And rewrite this to say "are encouraged to not use the opt-out flag" so if in
> the future we define another flag, we don't have to errata or Update: this
> document for this one line mentioning 0.
Yep, I actually noticed this exact bug too on a recent read. Agreed and
changed.
>The first
>hash is typically sufficient to discourage zone enumeration performed
>by "zone walking" an NSEC or NSEC3 chain.
>
> NSEC uses no hashing, so this sentence reads a little odd. Perhaps:
>
>The first
>hash with NSEC3 is typically sufficient to discourage zone enumeration
>performed by "zone walking" an unhashed NSEC chain.
>
>If NSEC3 must be used, then an iterations count of 0 MUST be used to
>alleviate computational burdens.
I think your first sentence is good, but the second sentence is a
duplicate with a later section.
> I think we need a sentence here (or in the section 2.4 above) that explains
> the
> iterations count of 0 means 1 hashing operation is done. Eg it is an "extra
> iteration count". I'd like to prevent implementors from thinking nsec3 can be
> unhashed completely.
You know, I'm sure we had a sentence about that in the past but must
have disappeared in some revision as I can't find it now. How's this:
Note that {{RFC5155}} describes the Iterations field to be "The
Iterations field defines the number of additional times the hash
function has been performed." This means that an NSEC3 record with an
Iterations field of 0 actually requires one hash iteration.
> Appendix D needs a note to the RFC Editor to remove itself.
Yep, already caught and added. Thanks.
> Appendix E lists a bunch of implementations. Normally, this would be placed in
> an Implementation Status section, that is removed before publication. Should
> this section really be contained within this document?
Yes, agreed per other discussions as well and guidance from RFC[mumble]
that talks about that it shouldn't be in the final document. I've
added a note for the RFCEditor to remove this section as well.
> "within the Internet" ? I'd probably use "on the Internet" :)
done
> "tamper-resistance proof" -> "tamper-resistant proof" ?
I figured out what you meant and changed it. :-P
> "repeating that hashing algorithm" -> "repeating that hashing using the same
> algorithm"
check
> Remove "ftp" from the example list in Section 2.3 as we deprecated it? The
> less
> credit we give it, the better :)
Ha, good point.
> in deploying both RFC4470 or NSEC3
>
> This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"
Done
>
> "and the zone resigned." -> "and the full zone needs to be
> resigned."
ok
> "and lower their default acceptable limits over time." -> "but lower their
> default acceptable limits over time."
gotcha
> There is a weird rendering of {RFC8914} instead of [RFC8914]
already fixed
> I think Petr Špaček would like to see his last name fixed :)
I'm sure he agrees.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Alvaro Retana's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Alvaro Retana via Datatracker writes: > Should this document formally Update RFC5155? Besides providing "guidance on > setting NSEC3 parameters", there is also Normative language that seems similar > to what is in rfc5155, but not the same. For example: > > In §3.2 this document says: > >Validating resolvers MAY return an insecure response to their clients >when processing NSEC3 records with iterations larger than 0. Note >also that a validating resolver returning an insecure response MUST >still validate the signature over the NSEC3 record to ensure the >iteration count was not altered since record publication (see >[RFC5155] section 10.3). > > I couldn't find text in rfc5155 about how returning insecure responses is > optional, but I did find this in §10.3 that seems related to the validation > requirement: > >A resolver MAY treat a response with a higher value as insecure, >after the validator has verified that the signature over the NSEC3 >RR is correct. > > Reading further, §3.2 does say that "this specification updates [RFC5155]", > but > there's no indication in the header or anywhere else. As discussed in other threads, the replacement version will update 5155. And yes, I agree that the returning of insecure for large values is not spelled out in a really strong way (and is one of the reasons I think the DNSOP WG thinks our document is a good update as we specify this with greater clarity). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Francesca Palombini's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Francesca Palombini via Datatracker writes: Hi Francesca, > Before reading Alvaro's comment, I was going to bring up that the following > paragraph in Section 3.2 could be confusing for a reader who is aware of the > "Updates" RFC header. > >Note that this specification updates [RFC5155] by significantly >decreasing the requirements originally specified in Section 10.3 of >[RFC5155]. See the Security Considerations for arguments on how to >handle responses with non-zero iteration count. > > I see that Alvaro is questioning if this doc should actually update 5155, I > personally don't have a strong opinion, and don't think it is absolutely > necessary, although I am curious to hear if there has been discussion in the > community about it. In any case I think it would be good to rephrase the above > paragraph to avoid saying that this doc updates 5155 when it doesn't. I think all of these issues have been taken care by adding an Updates clause, and mentioned in other threads. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Roman Danyliw via Datatracker writes: > ** I support Paul Wouter’s DISCUSS position. Like Alvaro and Francesca also > commented, this document appears to be changing the behavior of RFC5155. It > should formally update it in the meta data. Specifically: As discussed in other threads, the next version will be marked as updating RFC5115. > ** Section 2. >The following sections describe recommendations for setting >parameters for NSEC3 and NSEC3PARAM. > > I don’t believe this is accurate. There are few tangible recommendations > about > iterations or salts in this section. That’s in Section 3. How's this instead: The following sections describes the background of the parameters for the NSEC3 and NSEC3PARAM resource record types. > ** Section 2.2. >In general, NSEC3 with the Opt-Out flag enabled >should only be used in large, highly dynamic zones with a small >percentage of signed delegations. Operationally, this allows for >fewer signature creations when new delegations are inserted into a >zone. This is typically only necessary for extremely large >registration points providing zone updates faster than real-time >signing allows or when using memory-constrained hardware > > Qualitative scales such as “large … dynamic zones” and “extremely large > registration points” used. Can the operational experience informing these > statements be cited to suggest the scale? That's both a fair point but hard to fix. In early versions of this document, we used more strict wording in places (but not for this case). But in the end we're trying to address a sliding problem, and there is no perfect line to be drawn. How about if we end the paragraph with this: Operators considering the use of NSEC3 are advised to fully test their zones deployment architectures and authoritative servers under both regular operational loads to determine the tradeoffs using NSEC3 instead of NSEC. > ** Section 3.1. >Operators are encouraged to forgo using a salt entirely by using a >zero-length salt value instead (represented as a "-" in the >presentation format). > > Section 2.4 seemed to take a stronger position on the lack of utility of the > salt. Is there a reason normative language isn’t being used? Good point. I've changed it to this: Operators SHOULD NOT use a salt by indicating a zero-length salt value instead (represented as a "-" in the presentation format). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Andrew Alston's Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)
Hi Andrew, Sorry for the delay. Andrew Alston via Datatracker writes: > I've been sitting trying to work out in my mind if a BCP document should be > requesting code points - and if I should change the position from a no > objection to a discuss - and the more I think about this - I feel that a > discuss here is probably the right option. My understanding is that the IESG resolved this DISCUSS during the IESG meeting and that it's to remain a BCP. > Having read through the document, I would also like to support Paul's discuss > since the document does seem to update RFC5155. I also would like to second > what Murray said about it seeming a little strange to see a BCP document > updating a standards track document. The next version will indeed have an update clause. > Finally - I was a little surprised to see IANA actions in a document > entitled "guidance for" - not sure if anyone else agrees with me, > but it seems strange to see a BCP document requesting IANA actions So the IANA action is asking for an EDE code point. I believe this was also resolved in the IESG teleconference too. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] More input for draft-ietf-dnsop-dnssec-bcp?
Paul Hoffman writes: > > However, I noticed that three of the RFCs listed in the draft are > > from 202x, and likely more will have to be added in the future. That > > made me wonder: > > > > How do we update this collection? > > That's an excellent question! The likely, not-excellent answer is "we > don't". That is, if you look at similar documents for other protocol > sets like SIP and IPsec, they were never updated. Living documents -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Wes Hardaker writes:
> > Section 5, paragraph 1
> > ```
> > y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI
> > 10.17487/R
> >^^^
> > ```
> > Do not mix variants of the same word ("on-line" and "online") within a
> > single
> > text.
>
>
> I'm very confused now. That section looks nothing like you above text,
> nor is that text anywhere. And ditto with this one:
Arg, *I* was reading the wrong version.
Anyway, you're quoting how the tools produced the reference results with
their titles. I can't fix RFC4470.
> > Section 7.1, paragraph 2
> > ```
> > NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements
> > ^^
> > ```
> > Two consecutive dots.
Ditto.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Zaheduzzaman Sarker via Datatracker writes: > - the updating RFC 5155 issue like others have, so, lets support Paul's > discuss. I've added a reference. > - RFC 8174 should be in the normative reference. Also done. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Lars Eggert via Datatracker writes:
> DNS Error (EDE) {RFC8914} EDNS0 option of value (RFC EDITOR: TBD).
> {RFC8914} looks like a Markdown citation bug.
Yep. Fixed.
> ### Stray characters
>
> The text version of this document contains these HTML entities, which might
> indicate issues with its XML source: `č`, `Š`, and `Č`
Actually it's the markdown source -- I'll get the names fixed though.
> ### Grammar/style
>
> "Table of Contents", paragraph 1
> ```
> . . . . . . . . . . 10 Appendix D. Github Version of This Document . . . . .
>^^
> ```
> The official name of this software platform is spelled with a capital
> "H".
Good point. Better yet though, I've added a note that the rfc editor
should remove that section anyway.
These are done (but more following):
> Section 1.1, paragraph 1
> ```
> lag [RFC5155], which specifies whether or not that NSEC3 record provides pro
>^^
> ```
> Consider shortening this phrase to just "whether". It is correct though if you
> mean "regardless of whether".
>
> Section 2.3, paragraph 1
> ```
> w, ftp, mail, imap, login, database, etc) can be used to quickly reveal a lar
> ^^^
> ```
> A period is needed after the abbreviation "etc.".
>
> Section 5, paragraph 1
> ```
> y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/R
>^^^
> ```
> Do not mix variants of the same word ("on-line" and "online") within a single
> text.
I'm very confused now. That section looks nothing like you above text,
nor is that text anywhere. And ditto with this one:
> Section 7.1, paragraph 2
> ```
> NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements
> ^^
> ```
> Two consecutive dots.
Were you perhaps reading a different reference or something?
> "Appendix A.", paragraph 2
> ```
> Vixie * Tim Wicinski Appendix D. Github Version of This Document While this
> ^^
> ```
> The official name of this software platform is spelled with a capital
> "H".
I've marked that section to be deleted by the RFC Editor, but fixed that anyway.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Éric Vyncke via Datatracker writes: Thanks for the comments Éric, I've made the following changes: > ## Section 2 > > Suggest to change the title s/considerations/discussions/ as this section > explains the recommendations of section 3. > > ## Section 3.2 > > S/near the time of publication/near the time of publication of this document/ > ? > > ## Section 7.1 > > RFC 8174 should be normative > > # NITS > WRT to this: > ## Section 1 > Should "zone apex" be explained ? Probably not as its a term of art in DNS and hard to explain in a sentence. Anyone that follows the normative refs should understand it. > ## Appendix C > > I am not sure whether Peter Špaček appreciates his last name writing in the > I-D > ;-) (my first name, Éric, suffers from the same issue ;-) ) Yeah, I8N is a pain. I haven't figured out the right way to fix that in markdown source yet, but by the time its all published we'll get it fixed. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
John Scudder via Datatracker writes: > John Scudder has entered the following ballot position for > draft-ietf-dnsop-nsec3-guidance-08: No Objection Thanks John; I've made all of these changes: > -- > COMMENT: > -- > > Thanks for this document, I found it easy to read and useful. I have only a > few > nits: > > 1. In the Introduction: “This sacrifices the tamper-resistance proof of non- >existence offered by NSEC3” > > That doesn’t parse. Probably what you mean is “This sacrifices the > tamper-resistance of the proof of non-existence offered by NSEC3” (added “of > the”)? Or "... the tamper-resistant proof" would also work. > > 2. In Sections 2.4 and 3.1, I suggest “re-signing” (signing again) instead of > “resigning” (quitting). > > 3. Appendix B has “The table (Appendix C) >below” > > The “(Appendix C)” part appears to be a mistake? The table is uncaptioned, I > guess you either should caption it and xref that caption, or just remove the > xref? > > > -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Robert Wilton via Datatracker writes: > One minor point, I found it slightly confusing in various places as to whether > "iterations" meant "total number of interactions" or the "iterations > parameter" > that refers to the number of extra interactions. Hence I would suggest > changing "iterations" to "iterations parameter" or "extra iterations" or > "total > iterations" in various places depending on the context to ensure that this it > is clear/obvious in all places. Thanks Rob, I can see where people less familiar with the NSEC3 protocol could easily get misled and will look at the wording throughout the document. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Opsdir last call review of draft-ietf-dnsop-nsec3-guidance-08
Bo Wu via Datatracker writes: > 2.2. Flags > OLD > Which specifies whether or not that NSEC3 record provides proof of non- > existence or not. > > NEW > Which specifies whether or not that NSEC3 record provides proof of non- > existence. Thanks Bo for the help. I've made the requested change. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Genart last call review of draft-ietf-dnsop-nsec3-guidance-08
Meral Shirazipour via Datatracker writes: > Summary: This draft is ready to be published as BCP RFC. Gotta love such a short report. Thanks very much for your review! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance
Warren Kumari writes: > Please SHOUT loudly once you've had a chance to address these, and > I'll start IETF LC. Hi Warren, Thanks for the comments and suggestions. Looks good to us and I've made the changes and published -08. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Working Group Last Call for draft-ietf-dnsop-nsec3-guidance
Paul Hoffman writes: > One note: the first paragraph in Section 2.4 is misplaced. Section 2 > is about considerations while Section 3 is about recommendations. The > first paragraph of Section 2.4 should be moved to Section 3.1, > probably as the second paragraph there. Moved to the end of the 3.1 section, fyi, and integrated with other salt discussions there. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPCall for Adoption: DNSSEC as BCP: draft-hoffman-dnssec
Tim Wicinski writes: > This starts a Call for Adoption for: draft-hoffman-dnssec I support the concept of getting something down to a single reference, and believe that this document is a good start and should be accepted as a WG document. Personally, I'd prefer we produce a STD but that's more work, certainly. I'll also note it could probably be informational too, since it reads more like a roadmap than a BCP. But that's a very subjective statement. Finally, I have comments/suggestions about some of the text in the document but I'll refrain from mentioning those until it's adopted. > This call for adoption ends: 7 April 2022 Final comment: it does feel like the appearance of this document/desire and its subsequent call for adoption is doing an end-run around the previous poll for what should be adopted next. Though I understand the reasons for it trumping the rest of the "line", though that's a horrible misuse of a noun as the order of acceptance was never assured based on the poll results. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPWorking Group Last Call for draft-ietf-dnsop-nsec3-guidance
Tim Wicinski writes: > With the authors feeling there are no outstanding changes and most people are > happy with the current > version. So this means it's time: Note that two small changes have been introduced since -06 were published, which were just wording related changes. Here are the diffs: <zone owners about good values to select. Recent in academic studies <have shown that NSEC3 hashing provides only provides moderate <protection [GPUNSEC3][ZONEENUM]. --- >zone owners about good values to select. Recent academic studies >have shown that NSEC3 hashing provides only moderate protection >[GPUNSEC3][ZONEENUM]. and <iteration counts greater than 0, which will likely resulting in <returning a SERVFAIL to the client when no processed responses are --- >iteration counts greater than 0, which will likely result in >returning a SERVFAIL to the client when no acceptable responses are -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPDNSOP Updates, Document Status etc
Tim Wicinski writes: > draft-ietf-dnsop-nsec3-guidance-06 > > Authors are revising in accordance with WG advice– main result has been > slowly driving the iteration number down. FYI, there are no outstanding changes to be made to this document based on the last round of changes. In general, I believe most people are happy with it and its ready for LC. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Vladimír Čunát writes:
> On 26/02/2022 00.30, Wes Hardaker wrote:
> > Validating resolvers MAY choose to not respond to NSEC3 records with
> > iterations larger than 0.
>
> The -05 version sounds clearer here than -04 ("not respond" above) or
> -03. Thanks.
You should check -06 too -- I restructured it to read better (IMHO)
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-06.txt
Petr Špaček writes: > On 07. 03. 22 17:51, internet-dra...@ietf.org wrote: > > Filename: draft-ietf-dnsop-nsec3-guidance-06.txt > > I have no nits to report. > > Such thing have not happened to me for a long time - well done! :-) :-) :-) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-nsec3-guidance-06.txt published
I just published draft-ietf-dnsop-nsec3-guidance-06.txt which has much better text in 3.2 (Recommendation for Validating Resolvers). -06 resolves all outstanding issues that I'm aware of at the moment. (please don't read -05 -- it was broken [thanks Viktor]). -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-05.txt
Peter van Dijk writes:
> > Because hashing provides only moderate protection, as shown recently
> in academic studies of NSEC3 protected zones [GPUNSEC3][ZONEENUM].
>
> This sentence appears to be lacking a second half.
Changed to:
Recent in academic studies have shown that NSEC3 hashing provides only
provides moderate protection {{GPUNSEC3}}{{ZONEENUM}}.
> > Operators are encouraged to forget the salt entirely
>
> "forgo" perhaps? Or, easier on the eyes, "not use the salt at all"?
How about: Operators are encouraged to forgo using a salt entirely by using a
> > Note that this specification significantly decreases the requirements
> originally specified in Section 10.3 of [RFC5155].
>
> Should this document say "Updates: RFC5155" ?
Probably a good point. How about:
Note that this specification updates [RFC5155] by significantly
decreasing the requirements originally specified in Section 10.3 of
[RFC5155].
> > man-it-the-middle attacks
>
> man-in-the-middle
Actually changed to attacker-in-the-middle, but good catch!
> > Thus, validating resolver operators and software implementers SHOULD
> set the point above which a zone is treated for certain values of NSEC3
> iterations counts to the same as the point where a validating resolver
> begins returning SERVFAIL.
>
> Is "as insecure" missing after "treated"?
Yep, good catch.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-04.txt
internet-dra...@ietf.org writes: > Title : Guidance for NSEC3 parameter settings > Authors : Wes Hardaker > Viktor Dukhovni > Filename: draft-ietf-dnsop-nsec3-guidance-04.txt > Pages : 11 > Date: 2022-02-25 This addresses the comments from the recent conversations on the list. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt
Petr Špaček writes: > First, I perceive a "problem" with the current document structure: > >2. Recommendation for zone publishers . . . . . . . . . . . . . 3 > > 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > >3. Recommendations for deploying and validating NSEC3 records . 6 > > 3.1. Best-practice for zone publishers . . . . . . . . . . . . 6 > > 3.2. Recommendation for validating resolvers . . . . . . . . . 7 > > 3.3. Recommendation for Primary / Secondary relationships . . 7 > > It seems odd to have "2. Recommendation for zone publishers" followed > by "3.1 Best-practice for zone publishers". You bring up a good point.When looking at it though, 3.1 really does look written for zone publishers but actually maybe we should change the title of 2 is actually what's wrong. How about "NSEC3 parameter value considerations": 2. NSEC3 parameter value considerations . . . . . . . . . . . . 3 2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Recommendations for deploying and validating NSEC3 records . 5 3.1. Best-practice for zone publishers . . . . . . . . . . . . 6 3.2. Recommendation for validating resolvers . . . . . . . . . 6 3.3. Recommendation for Primary / Secondary relationships . . 7 > Either my understanding of relationship between terms "recommendation" > vs. "best practice" is wrong, or these should be somehow renamed. Say > "Background information about NSEC3 parameters" as name of section 2? > > Also there is now a SHOULD vs. MUST inconsistency between _content_ of > sections 2.3. Iterations and section 3.1. Best-practice for zone > publishers: Good catch; I took your suggestion about dropping that half-sentence. > The only other thing worth mentioning is a nit which I don't feel > strongly about: > > > 3.2. Recommendation for validating resolvers > >Note that a validating resolver MUST still validate the signature > >over the NSEC3 record to ensure the iteration count was not altered > >since record publication (see [RFC5155] section 10.3). > > Technically RRSIG validation is needed only if the resolver treats > some combination of parameters as insecure. If it is going to SERVFAIL > for e.g. large iteration value anyway then there is no point in > validating the RRSIG, I think. I think the reason is the error is different (eg EDE). You're right that the processing may be an overload (but if it is, you can always just drop it per the other thread too). Anyway, if others support this change we can discuss it further, but it's been discussed before. So to the others: please chime in if you agree and we want to revert the existing consensus based on this new thinking. > Additionally I've submitted PR#6 with purely editorial nits. Thank you! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Vladimír Čunát writes: > On 09/02/2022 22.41, Wes Hardaker wrote: > > So I've re-arranged things a bit to hopefully address the flow better. > Let em know if you think further improvements are warranted. > > I'd still probably suggest at least a minimalist change like: > -Note that a validating resolver MUST still validate the signature > +Note that a validating resolver returning an insecure response MUST still > validate the > signature > > But to me it's certainly not a big deal. (Though not changing this would > mean that > formally I wouldn't be exactly following the RFC.) I think there seems to be consensus about this, so I implemented your change. I think it's actually best to be as clear as possible as what's acceptable. IE, you shouldn't be trying to find hidden loopholes. So I added this: Validating resolvers MAY choose to not respond to NSEC3 records with iterations larger than 0. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt
internet-dra...@ietf.org writes: > A new version of I-D, draft-ietf-dnsop-nsec3-guidance-03.txt > has been successfully submitted by Wes Hardaker and posted to the > IETF repository. > > Name: draft-ietf-dnsop-nsec3-guidance > Revision: 03 Sorry the delay in resolving the discussions in December and getting a new version out. January was a very long deadline-month for me. I believe I've acted on all the recent suggestions (thank you!), and the document is now pretty much ready for WG last call. IMHO. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Vladimír Čunát writes:
> Note that a validating resolver MUST still validate the signature over
> the NSEC3 record to ensure
> the iteration count was not altered since record publication (see
> {{RFC5155}} section 10.3).
>
> It might be better to clarify that this "MUST" does not really apply to the
> SERVFAIL case. (The text
> around has changed recently.)
>
> I think this SERVFAIL will generally be best implemented by simply ignoring
> any NSEC3 above the
> corresponding limit. Maybe I'd even standardize the case that way, but I
> don't care really. It's an
> advantage unstated in the draft that this is very easy to do, leaving no room
> for bugs (e.g.
> unintentional downgrade opportunities).
So I've re-arranged things a bit to hopefully address the flow better.
Let em know if you think further improvements are warranted.
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Paul Vixie writes: > if we must say this, s/vendors/implementers/, please. some of us when > we play with dns or dnssec don't share our resulting code. --vixie Good catch; I've changed all references. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Matthijs Mekking writes: > Can we make use of the keyword MAY? This allows I think for text that > will not get out of date: > >Validating resolvers MAY return an insecure response when processing >NSEC3 records with iterations larger than 0. Validating resolvers MAY >also return SERVFAIL when processing NSEC3 records with iterations >larger than 0. This significantly decreases the requirements >originally specified in Section 10.3 of [RFC5155]. See the Security >Considerations for arguments on how to handle responses with non-zero >iteration count. Thanks for the good text Matthijs. I've added it tot he bottom of the existing 3.2, which seems to be where consensus indicated it should go. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Petr Špaček writes: > I believe that this property renders salt practically useless, so let > me propose a modified section 2.4: [snip] Thanks for the text and it seems well agreed upon, so I replaced section 2.4 with your text after making some editing related tweaks. Feel free to re-read it and tell me any of my edits were incorrect or changed the meaning :-) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Matthijs Mekking writes: > 3.2. Recommendation for validating resolvers > > I understand why the new text is here, but I think this now actually > gives too little advice for operators and vendors. > > I know, this is a vague comment, I need to think about it a bit more. Whoops, good catch thanks. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
Petr Špaček writes: > > 3.1. Best-practice for zone publishers > > I wonder if we can make the requirement even stronger by saying "If > > NSEC3 must be used, then an iterations count of 0 MUST be used to > > alleviate computational burdens." (MUST instead of SHOULD). > > Or is there a valid reason for zone publishers to set iterations to > > a non-zero value? > > This section is IMHO missing a scary warning to explain the > reasons. Let add one couple sentences (+ "extra" keyword to > differentiate it from the implicit single iteration): > > -- > If NSEC3 must be used, then an extra iterations count of 0 SHOULD be > used to alleviate computational burdens. > > Please note that extra iteration counts other than 0 increase impact > of resource CPU-exhausting DoS attacks, and also increase risk of > interoperability problems. > -- Sentence added -- seems wildly agreed upon. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
internet-dra...@ietf.org writes: > Title : Guidance for NSEC3 parameter settings > Authors : Wes Hardaker > Viktor Dukhovni > Filename: draft-ietf-dnsop-nsec3-guidance-02.txt > Pages : 10 > Date: 2021-11-24 This version attempts to take into account the discussion from the WG meeting at IETF 112. Concrete text proposals appreciated so we can finish this work and publish it. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Miek Gieben writes: > [ Quoting in "Re: [DNSOP] nsec3-parameters opinio..." ] > >The document should strongly discourage any use of NSEC3 > > I would very much see a sentence/paragraph stating this in the > document as well. Folks, can we boil this down to a concrete suggestion. Section 3.1 already says this: First, if the operational or security features of NSEC3 are not needed, then NSEC SHOULD be used in preference to NSEC3. NSEC3 requires greater computational power for both authoritative servers and validating clients. Specifically, there is a non trivial complexity in finding matching NSEC3 records to randomly generated prefixes within a DNS zone. NSEC mitigates this concern, and if NSEC3 must be used then selecting a low iterations count will help alleviate this computational burden. Note that deploying NSEC with minimally covering NSEC records [RFC4470] also incures a cost, and zone owners should measure the computational difference in deploying both RFC4470 or NSEC3. Which is fairly strong (SHOULD [use NSEC]) with reasoning behind the statement already. How do you think we should specifically change that text? -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Petr Špaček writes: Thanks for the detail notes Petr, very helpful. > From my point of view the RFC does not need to stick to the value > currently implemented in resolvers. Good point, and maybe the right phrasing I should have used should have been "what value would implementations refuse to switch to"? In part, I worry that code authors would object to having just changed something and refused to change again. It seems like reports are overcoming that problem though :-) [I'm not sure we're at zero yet...] -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Vladimír Čunát writes: > I'm convinced that 150 was just a quick stop-gap compromise and that > from the start vendors expected that dnsop might set it lower later. > Therefore I don't think this *argument* for keeping 150 is really > valid. Thanks; as I said in the original, I think we need to hear from most implementations in order to publish as an RFC. So... > As for Knot Resolver, I see no problem in setting the hard limit > lower, especially if that gets published in this RFC. Excellent, thank you! -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Miek Gieben writes: > To update, my 'wants' would actually be 0. Thanks Miek, Its always hard to interpret what people say into hard numbers :-) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] nsec3-parameters opinions gathered
Folks, I was waiting for the last discussion to die down (and then, um, for me to finally examine the opinions). The results are in from the people that weighed in: | who | wants | accepts| |--+---+| | Peter van Dijk | 0 | anything low | | Matthijs Mekking | 150 | 150 -- vendors implemented | | Miek Gieben | 100 | or lower | | Paul Vixie | 0 || | Vladimír Čunát | any || | Viktor Dukhovni | 0 | 100 or 150 | I think the consensus is "everyone wants low", but most are willing to accept any value up to 150. The most important sticking point is there are 4 implementations (thank you for the links Matthijs) that have implemented 150. Since DNSOP strives for implementations of specs, I think this is the number we should publish *unless the vendors speak up and say they'll drive lower*. 150 is higher than almost everyone would ideally like, and zero would certainly be a nice target. But without implementation... -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] CFP for DINR 2021 workshop-Nov. 16 for early DNS research
We failed to send out a reminder, unfortunately, so we're extending the submission date to this Friday (29 Oct 2021 11:59:59pm PDT). As a reminder: they're expected to be short abstracts about things you wish to discuss or research you're working on -- IE, it shouldn't be a huge effort to submit something. FYI, I'm CCing the new DANCE WG since I think DANCE is a great example how we're using the DNS in potentially new ways and DANCE participants may be interested in participating as well. Start of forwarded message ---- From: Wes Hardaker To: dnsop@ietf.org Cc: John Heidemann Subject: CFP for DINR 2021 workshop-Nov. 16 for early DNS research Date: Mon, 04 Oct 2021 08:41:38 -0700 Greetings, dnsop. Last year we held a virtual research conference called "DINR" which we invited dnsop working group participants to and we'd like to extend that again this year. Here's the CFP: - We would like to invite you to our upcoming virtual workshop on "DNS and Internet Naming Research Directions" (DINR). We will be holding this workshop virtually over Zoom on 2021-11-16 from 14:00 to 20:00 UTC (that's 07:00-13:00 PDT on the US west coast). If you're intereseted in DNS-related topics, infrastructure, have early early DNS or naming work to share, or you want to hear about other people's work in those areas, we'd love to have you join us. The principle focus of the workshop will be on DNS and Internet naming, particularly on open problems, preliminary work, and tools that help both. We're planning for a very interactive day of discussion and short talks. We are soliciting short (1 page text + 1 page references) abstracts from people who are interested presenting. Abstracts are due soon (October 26), but they're short. Co-chairs are John Heidemann and Wes Hardaker (both at USC/ISI). For details about DINR2021, see https://ant.isi.edu/events/dinr2021/ . It builds on last year's DINR2020, see https://ant.isi.edu/events/dinr2020/ what we learned. In addition, we will have a short tutorial about the DIINER experimental DNS testbed and datasets on Nov. 18. For details about the tutorial, see https://ant.isi.edu/events/dinr2021#tutorial Please let us know if you're interested, or register your abstract at https://ant.isi.edu/dinr2021sub . -John and Wes -- Wes Hardaker USC/ISI End of forwarded message -- Wes Hardaker My Pictures: http://photos.capturedonearth.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-intentionally-temporary-insec-01.txt
Peter van Dijk writes: > > It remains to be debated whether these ideas that you shouldn't use > > unless you have to should eventually be published as an RFC. > > I'm torn on this one. Sometimes going insecure is what has to happen, > and for those cases, operational guidance is good to have. Thanks Peter. I agree completely on the "I'm torn" feeling. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
