Re: [DNSOP] [Ext] Call for Adoption: draft-hardaker-dnsop-rfc8624-bis, must-not-sha1, must-not-ecc-gost
Hello, At 04:54 PM 30-04-2024, Paul Wouters wrote: On Tue, 30 Apr 2024, Paul Hoffman wrote: Is that something within the realm of ICANN? Perhaps the DNS Tech Day ? You ask those questions sounding as if ICANN staff had not already done so. Why not share the data if you have some? This is the list of TLDs affected: [snip] int.(international orgs - important) Matters related to int. are discussed in RFC 9121. It's a good idea to get some data. It's not a good idea to take a decision by fiat on matters directly related treaty-based organizations. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Comments on draft-hardaker-dnsop-must-not-ecc-gost-00
Hi Wes, Warren, 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? :-) Appendix C has a reference to draft-hardaker-dnsop-must-not-sha1 instead of this draft. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] on private use TLDS: .interNAL -> .LAN
Hi Toerless, At 10:53 AM 27-02-2024, Toerless Eckert wrote: I don't think ICANN are the authoritative experts to define how to best operate private DNS zones, especially not modifications to configs if not source code to automatically filter out DNS requests for that zone to avoid the overload of public DNS servers with requests for it - something which ICANN is suggesting is what .internal can achieve. And which i think it may not be able to achieve unless appropriate operational recommendations exist and are applied. And if i was a DNS operator, i would hope IETF would provide those recommendations. The IETF angle is that there is a Standards Track memo which specified what to do when special handling of a DNS label is required. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis
Hello, At 02:07 PM 03-06-2020, Tim Wicinski wrote: As we stated in the meeting and in our chairs actions, we're going to run regular call for adoptions over next few months. We are looking for *explicit* support for adoption. This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis There is the following in Section 1: "Familiarity with DNSSEC and with GOST signature and hash algorithms is assumed in this document." I am not familiar with the cryptographic aspects [1] of the GOST R 34.11-2012 to perform an adequate review of that standard. The current draft is well-written. It probably needs some work before it is ready for a Last Call. I suggest consideration what to do about RFC 5933 given that the intended status of the document. Regards, S. Moonesamy 1. The Security Area Directors will likely ask whether the document was reviewed by the relevant research group. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
Hi Roy, Ed, At 08:12 AM 12-06-2020, Tim Wicinski wrote: Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. It is difficult for me to take a position on the adoption of this draft as I don't have enough information to do that. I have a few questions: I took a quick look at the draft. There is a request to Public Technical Identifiers in Section 6. Isn't that beyond DNS operations? Will the working group consult with the liaisons to other organizations? Is ICANN experiencing issues developing policies for the DNS Root Zone? Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Client Validation - filtering validation?
Hi Paul, At 06:38 AM 28-04-2020, Paul Wouters wrote: There is only one method where you can trust the filtering service. That is that they offer you the filtered data in a neutralized fashion. I have already been waiting a few years for the RPZ draft to pass the ISE publication process so the IETF can work on the bis document that moves the censored data into the authoritative section. That way, you get all the data innoculated. Clients not supporting this will not see this data and get filtered. Clients supporting this can talk to an enduser if one is available to say their data was filtered and present a choice on accepting the filter or not. I have poked Paul Vixie and the ISE a number of times on the RPZ draft. I even gave them another full review, but it seems nothing is happening to move this draft forward. I found a WG draft (expired) from 2017 about RPZ. I am not sure why it stalled in DNSOP. There is also a 2018 draft (expired). I vaguely recall looking at a draft. However, proposed changes were not accepted. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Protocol Action: 'Moving DNSSEC Lookaside Validation (DLV) to Historic Status' to Proposed Standard (draft-ietf-dnsop-obsolete-dlv-02.txt)
Hello, At 09:40 AM 04-11-2019, The IESG wrote: The IESG has approved the following document: - 'Moving DNSSEC Lookaside Validation (DLV) to Historic Status' RFC4431 and RFC 5074 were reclassified as "Historic" on November 4, 2019. However, the RFC Editor lists those two RFCs [1][2] as "Informational". Regards, S. Moonesamy 1. https://www.rfc-editor.org/info/rfc4431 2. https://www.rfc-editor.org/info/rfc5074 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?
Hi Peter, At 04:16 AM 07-02-2019, Petr Špacek wrote: here is a quiz for experienced RFC archeologists: https://tools.ietf.org/html/rfc1035#section-5.2 section 5.2. Use of master files to define zones does not mention NS at apex at all, but it does explicitly mention SOA at apex. Can it be interpreted as if NS at apex is not mandatory? Funnily enough https://tools.ietf.org/html/rfc1035#section-5.3 has an example which as NS at apex, but it is not clear from the text above. Is it mandatory or not? Should I submit erratum for RFC 1035? RFC 1035 assumes that the reader is familiar with RFC 1034. Section 5.2 of RFC 1035 discusses about validity checks to be performed on the master files used to define zones. I would read Section 4.2 of RFC 1034 to understand the technical considerations, e.g. is a NS needed or not. The examples in RFC 1035 are "primarily pedagogical". I suggest taking into consideration that RFC 1035 is part of STD 13 for errata processing. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-capture-format
Hi Tim, At 05:32 PM 06-07-2018, Tim Wicinski wrote: One thing which arose early in the process was the issue of IPR and how it would be resolved. The simple answer is that it is resolved farther up the process chain. I spent time reading RFC 3979 on this topic: That RFC is obsolete. What is the IPR issue? Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Extended CNAME (ENAME)
Hi John, At 10:43 21-05-2014, John Levine wrote: See RFC 1123, section 5.2.2. Tony Finch already commented about RFC 1123. That section has been replaced (see RFC 5321). Section 8.7 of RFC 6409 is applicable for mail submission and CNAME. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-delegation-trust-maintainance-13.txt (Automating DNSSEC Delegation Trust Maintenance) to Informational RFC
because it gets different answers on different checks or CDS RR validation fails. Does that mean that the entity will be confused? Shouldn't the issue be about inconsistent information? By automating the maintenance of the DNSSEC key information (and removing humans from the process), we expect to decrease the number of DNSSEC related outages, which should increase DNSSEC deployment. What does the above have to do with Security Considerations? How many of the DNSSEC-related outages are due to human error? Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Hi Ted, At 06:02 15-05-2014, Ted Lemon wrote: I think it's worth documenting this option because there's a code reserved for it, but I think it's highly questionable whether it makes the internet better, because it encourages practices with DNS that wind up violating the expectations resolvers might have for consistency of zones and so on. See for instance my DISCUSS here: http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ballot/ This wound up opening up a huge can of worms about the various assumptions that CDNs make about how resolvers will process DNS records, how this mechanism interacts with DNSSEC, etc. These things are definitely worth documenting, because people are doing them. But whether they improve the internet is very much open for debate. The CDNI document specifies other ways of accomplishing the same thing that I think are much less fraught. What makes the internet better is usually subject to discussion. The words internet and better in the previous sentence are not defined. :-) I sent a few comments about that CDNI draft. The DNS discussion in the draft was problematic. It is worth documenting what people are doing. It is worthwhile to consider whether the mechanism should be standardized by the IETF. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] call to work on edns-client-subnet
Hi Ted, At 04:56 16-05-2014, Ted Lemon wrote: Did you feel that your comments were adequately addressed by the working group? I gave up on reading the first response to my comments as I did not want to push back strongly; it's an effort and it can be viewed as antagonistic. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Current DNSOP thread and why 1024 bits
Hi Ed, At 06:30 02-04-2014, Edward Lewis wrote: I found that there are two primary reasons why 1024 bits is used in zone signing keys. One - peer pressure. Most other operators start out with 1024 bits. I know of some cases where operators wanted to choose other sizes but were told to follow the flock. Two - it works. No one has ever demonstrated a failure of a 1024 bit key to provide as-expected protection. My short comment would be Yes to the above. The problem might be the follow the flock as there is an assumption that someone looked at the details before choosing the 1024 bit key. What does it matter from a security perspective? DNS messages are short lived. It's not like we are encrypting a novel to be kept secret for 100 years. With zone signing keys lasting a month, 6 months, or so, and the ability to disallow them fairly quickly, what's the difference between this so-called 80 or 112 bit strength difference? Yes, I understand the doomsday scenario that someone might guess my private key and forge messages. But an attack is not as simple as forging messages, it takes the ability to inject them too. That can be done - but chaining all these things together just makes the attack that much less prevalent. For context, the discussion is about a ZSK. There is a theory that it would take under a year and several million (U.S.) dollars to break 1024 bits. It has been said (not on this mailing list) that an organization could do it within a shorter time. It's not a good idea to wait for the demonstration as it can raise concerns about the entity which chose the key. As a general comment I tried to find out which NIST recommendations are being discussed in respect to DNSSEC. The requirements mentioned by Joe Abley refers to NIST SP 800-78. That document is about Cryptographic Algorithms and Key Sizes for Personal Identity Verification. Is that the NIST recommendation on which this discussion is based? Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Current DNSOP thread and why 1024 bits
Hi Scott, At 10:13 02-04-2014, Rose, Scott wrote: The only DNSSEC related NIST SP's are 800-57 and 800-81-2. SP 800-57 is in 3 parts, part one is general key considerations and part 3 covers specific uses like DNSSEC. It's showing its age though. The US Federal policy (now) is 2048 bit RSA for all uses, DNSSEC has a special exemption for 1024 bit ZSK's if desired (to reduce risks of fragmented packets). I do know some .gov zones using 2048 bit KSK and ZSK's as local policies can call for stronger keys. By 2015, .gov/mil zones should migrate to ECDSA. Not sure if that will happen given the track record, but that is the roadmap. Thanks for the above information. Adding to it, 1024-bit RSA keys are allowed until 2015. There is an explanation about that recommendation, i.e. it's not only about packet size. Regards, S. Moonesamy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
At 15:47 27-03-2014, Joe Abley wrote: There was a plan underway to roll the KSK. I was at ICANN briefly when that started (I spoke publicly, albeit briefly about it in the dnsop meeting in Berlin). I'm no longer at ICANN and hence no longer have anything authoritative to say, but it seems plausible that the events leading up to NTIA's announcement the other week caused some delays or rescheduling of the KSK roll project. A KSK roll would be a good opportunity to change the key size. Yes, assuming that there is a reason for such a change [1]. I could not find any report about the outcome of the Rollover consultation. Regards, S. Moonesamy 1. To date, despite huge efforts, no one has broken a regular 1024-bit key; in fact, the best completed attack is estimated to be the equivalent of a 700-bit key. An attacker breaking a 1024-bit signing key would need to expend phenomenal amounts of networked computing power in a way that would not be detected in order to break a single key. Because of this, it is estimated that most zones can safely use 1024-bit keys for at least the next ten years. That was the IETF Consensus in 2012. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
