Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)
Hi Paul, Murray & Warren, Paul, Sorry, I had missed your update. Thanks for addressing my concerns. I have now cleared. Murray, I think that this is now with you to check if your concerns have been addressed before Warren can approve. Regards, Rob From: Paul Vixie Date: Thursday, 1 February 2024 at 02:56 To: Rob Wilton (rwilton) Cc: draft-ietf-dnsop-avoid-fragmentat...@ietf.org , dnsop@ietf.org , be...@nlnetlabs.nl , swo...@pir.org , tjw.i...@gmail.com , The IESG , Mahesh Jethanandani , dnsop-cha...@ietf.org , Warren Kumari Subject: Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS) thanks rob for your long service. we'll do as you suggest. Rob Wilton (rwilton) wrote on 2024-01-29 02:48: > Hi Authors, > > Just a note/reminder that I am stepping down as an AD in March. I don’t > think that I’ve seen any reply to my DISCUSS comments (perhaps the > authors and/or WG are still discussing the resolution), but if you are > able to speed this up at all so that I can clear my discuss before I > step down that would be preferable. Actually, if you manage to clear > all the DISCUSSes on this doc before March, so that Warren can approve > it before the new IESG is seated, that would probably make both yours > and Warren’s lives slightly easier at the transition. > > Regards, > > Rob > > *From: *DNSOP on behalf of Robert Wilton via > Datatracker > *Date: *Tuesday, 2 January 2024 at 15:41 > *To: *The IESG > *Cc: *draft-ietf-dnsop-avoid-fragmentat...@ietf.org > , dnsop-cha...@ietf.org > , dnsop@ietf.org , > be...@nlnetlabs.nl , swo...@pir.org > , tjw.i...@gmail.com , > tjw.i...@gmail.com > *Subject: *[DNSOP] Robert Wilton's Discuss on > draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS) > > Robert Wilton has entered the following ballot position for > draft-ietf-dnsop-avoid-fragmentation-16: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > > > -- > DISCUSS: > -- > > Hi, > > Thanks for this document. > > I'm echoing Paul's and the SECDIR review comments here on the use of MAY in > recommendations (since everywhere you see MAY it is equally valid for an > interpretation to treat it as "MAY NOT"), but I think that this makes the > document, as a proposed BCP, unclear enough that I'm raising this to > level of a > DISCUSS. > > (1) p 3, sec 3.1. Recommendations for UDP responders > > At the time of writing, most DNS server software did not set the DF > bit for IPv4, and many OS kernel constraints make it difficult to set > the DF bit in all cases. Best Current Practice documents should not > specify what is currently impossible, so R2, which is setting the DF > bit, is "MAY" rather than "SHOULD". > > I think that this recommendation, particularly because it is using RFC 2119 > language, is unclear. I would suggest rephasing this to something like: > > R2. Where supported, UDP responders SHOULD set IP "Don't Fragment > flag (DF) bit" [RFC0791] on IPv4. > > (2) p 3, sec 3.2. Recommendations for UDP requestors > > R6. UDP requestors SHOULD limit the requestor's maximum UDP payload > size to the RECOMMENDED size of 1400 or a smaller size. > > I find this recommendation to be unclear because it mixes both a > "SHOULD" and > "RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies > to. Is > the recommendation (i) that UDP requestors should limit the maximum UDP > payload. Or (ii) is the recommendation that a limit of 1400 be used, or > (iii) > perhaps both. Maybe rewording this to something like the following > would help: > > R6. UDP requestors SHOULD limit the requestor's maximum UDP payload > size to 1400 bytes, but MAY limit the maximum UDP payload size to a > smaller size on small MTU (less than 1500 bytes) networks. > > or, > > R6. UDP requestors SHOULD limit the requestor's maximum UDP payload > size. It is RECOMMENDED to use a limit of 1400 bytes, but a smaller > limit MAY be used. > > (3) p
Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)
Hi Authors, Just a note/reminder that I am stepping down as an AD in March. I don’t think that I’ve seen any reply to my DISCUSS comments (perhaps the authors and/or WG are still discussing the resolution), but if you are able to speed this up at all so that I can clear my discuss before I step down that would be preferable. Actually, if you manage to clear all the DISCUSSes on this doc before March, so that Warren can approve it before the new IESG is seated, that would probably make both yours and Warren’s lives slightly easier at the transition. Regards, Rob From: DNSOP on behalf of Robert Wilton via Datatracker Date: Tuesday, 2 January 2024 at 15:41 To: The IESG Cc: draft-ietf-dnsop-avoid-fragmentat...@ietf.org , dnsop-cha...@ietf.org , dnsop@ietf.org , be...@nlnetlabs.nl , swo...@pir.org , tjw.i...@gmail.com , tjw.i...@gmail.com Subject: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS) Robert Wilton has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ -- DISCUSS: -- Hi, Thanks for this document. I'm echoing Paul's and the SECDIR review comments here on the use of MAY in recommendations (since everywhere you see MAY it is equally valid for an interpretation to treat it as "MAY NOT"), but I think that this makes the document, as a proposed BCP, unclear enough that I'm raising this to level of a DISCUSS. (1) p 3, sec 3.1. Recommendations for UDP responders At the time of writing, most DNS server software did not set the DF bit for IPv4, and many OS kernel constraints make it difficult to set the DF bit in all cases. Best Current Practice documents should not specify what is currently impossible, so R2, which is setting the DF bit, is "MAY" rather than "SHOULD". I think that this recommendation, particularly because it is using RFC 2119 language, is unclear. I would suggest rephasing this to something like: R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. (2) p 3, sec 3.2. Recommendations for UDP requestors R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to the RECOMMENDED size of 1400 or a smaller size. I find this recommendation to be unclear because it mixes both a "SHOULD" and "RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies to. Is the recommendation (i) that UDP requestors should limit the maximum UDP payload. Or (ii) is the recommendation that a limit of 1400 be used, or (iii) perhaps both. Maybe rewording this to something like the following would help: R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to 1400 bytes, but MAY limit the maximum UDP payload size to a smaller size on small MTU (less than 1500 bytes) networks. or, R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size. It is RECOMMENDED to use a limit of 1400 bytes, but a smaller limit MAY be used. (3) p 3, sec 3.2. Recommendations for UDP requestors R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. As written, I don't think that this is really a recommendation. Either it is a just a statement or fact (in which case it is not a recommendation), or it should be upgraded to a SHOULD. (4) p 4, sec 3.2. Recommendations for UDP requestors R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. R8. DNS responses may be dropped by IP fragmentation. Upon a timeout, to avoid resolution failures, UDP requestors MAY retry using TCP or UDP with a smaller EDNS requestor's maximum UDP payload size per local policy. Again, I think that this document would be clearer if this was a SHOULD rather than a MAY. Regards, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] FW: Approved: draft-ietf-dnsop-alt-tld-25.txt
Hi DNSOP WG, I just wanted to let you know that I have approved draft-ietf-dnsop-alt-tld-25 and hence it will move on to the RFC editor queue. I appreciate that this document hasn't been the easiest to move through the process but I hope that it will prove beneficial to IETF and the DNSOP WG in the longer term. I would like to thank the WG, the chairs, and the authors for all their reviews and help during the process. Regards, Rob // As responsible AD for this document. -Original Message- From: iesg On Behalf Of Robert Wilton via Datatracker Sent: 06 May 2023 19:33 To: i...@iesg.org Subject: Approved: draft-ietf-dnsop-alt-tld-25.txt Secretary (Bcc'ed): draft-ietf-dnsop-alt-tld-25.txt has been approved. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps
Hi DNSOP WG, The liaison statement has been sent, and can be found here: https://datatracker.ietf.org/liaison/1821/ Regards, Rob From: DNSOP On Behalf Of Rob Wilton (rwilton) Sent: 08 March 2023 10:30 To: Joe Abley ; d...@virtualized.org; George Michaelson Cc: dnsop@ietf.org; draft-ietf-dnsop-alt-...@ietf.org; dnsop-cha...@ietf.org Subject: Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps Hi Joe, David, George, My impression, from discussions with folks who know a lot more about ICANN that I do, is that the relevant folks in ICANN are likely already aware of this proposal, and if they had concerns that these would already have been flagged either through a formal liaison to the IETF or via individual contributor feedback in DNSOP WG or the ADs. Hence the goal here is not to ask ICANN for any permission or consent to publish, since I think that doing so would be a mistake by potentially mudding the waters around Special Use Domain Names, and potentially creating a new ad-hoc process for approval between the IETF and ICANN. This is clearly outside my remit as the responsible AD for this document. I’m not an expert in this area, but there have been previous liaison statements to ICANN regarding the “Special-Use Domain Name” registry, and my interpretation of that previous exchange is that neither the IETF nor ICANN wants to formalize or create extra process around this, and that maintaining open communication between the two organizations should be sufficient to handle the infrequent cases where this comes up. There are also some who have argued that we don’t need to send a liaison to ICANN at all, which may be technically correct, but letting ICANN know what we are doing seems to be polite and should help maintain a good working relationship between the two organizations. Hence, the aim of the liaison is to politely inform the ICANN Board about what stage the document is at, and to point out the standard IETF procedures that any individuals may use to provide comments during the last-call process. I agree that 4 weeks would not be long enough for ICANN (board or community) to provide a formal response, but we are not asking for that anyway. I do think that 4 weeks would be long enough for the ICANN board to share the liaison with the ICANN community and that should be sufficient time for individual participants in ICANN to absorb the document and provide comments if they wish to do so. I also think that 4 weeks should be enough time for the ICANN board to say, “Woah! We (or the ICANN community) are really worried about this document, can we have more time to think about this please?”, and if that were to happen then of course their response would be considered carefully whilst we figure out the next steps. Given my first paragraph, I’m hopeful that such a communication will not be forthcoming. Finally, it is worth noting, and thanking, the DNSOP WG chairs, Harald, and several members of the IAB, who have helped craft the liaison statement and agree to the approach that is being taken here. Once sent, I will share a pointer to the liaison statement with the DNSOP WG. Hopefully this addresses your questions and concerns. Regards, Rob // Wearing a “Responsible AD for this document only” hat. From: Joe Abley mailto:jab...@hopcount.ca>> Sent: 07 March 2023 23:48 To: d...@virtualized.org<mailto:d...@virtualized.org>; Rob Wilton (rwilton) mailto:rwil...@cisco.com>> Cc: dnsop@ietf.org<mailto:dnsop@ietf.org>; draft-ietf-dnsop-alt-...@ietf.org<mailto:draft-ietf-dnsop-alt-...@ietf.org>; dnsop-cha...@ietf.org<mailto:dnsop-cha...@ietf.org> Subject: Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps On Tue, Mar 7, 2023 at 15:56, David Conrad mailto:d...@virtualized.org>> wrote: 4 weeks for ICANN (which? Organization, Board, Community, all 3?) to provide feedback? (That feels sort of like the ITU asking "the IETF" for feedback on an IP-related protocol document in 4 weeks.) Did the IETF (also which?) provide feedback on this similar request for feedback? https://www.icann.org/en/public-comment/proceeding/proposed-procedure-for-selecting-a-top-level-domain-string-for-private-use-13-01-2023 It seems like the answer is no. Perhaps it would be useful for someone to decide whether these ships are intentionally passing in the night or whether more attention to navigation is required. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps
Hi Joe, David, George, My impression, from discussions with folks who know a lot more about ICANN that I do, is that the relevant folks in ICANN are likely already aware of this proposal, and if they had concerns that these would already have been flagged either through a formal liaison to the IETF or via individual contributor feedback in DNSOP WG or the ADs. Hence the goal here is not to ask ICANN for any permission or consent to publish, since I think that doing so would be a mistake by potentially mudding the waters around Special Use Domain Names, and potentially creating a new ad-hoc process for approval between the IETF and ICANN. This is clearly outside my remit as the responsible AD for this document. I’m not an expert in this area, but there have been previous liaison statements to ICANN regarding the “Special-Use Domain Name” registry, and my interpretation of that previous exchange is that neither the IETF nor ICANN wants to formalize or create extra process around this, and that maintaining open communication between the two organizations should be sufficient to handle the infrequent cases where this comes up. There are also some who have argued that we don’t need to send a liaison to ICANN at all, which may be technically correct, but letting ICANN know what we are doing seems to be polite and should help maintain a good working relationship between the two organizations. Hence, the aim of the liaison is to politely inform the ICANN Board about what stage the document is at, and to point out the standard IETF procedures that any individuals may use to provide comments during the last-call process. I agree that 4 weeks would not be long enough for ICANN (board or community) to provide a formal response, but we are not asking for that anyway. I do think that 4 weeks would be long enough for the ICANN board to share the liaison with the ICANN community and that should be sufficient time for individual participants in ICANN to absorb the document and provide comments if they wish to do so. I also think that 4 weeks should be enough time for the ICANN board to say, “Woah! We (or the ICANN community) are really worried about this document, can we have more time to think about this please?”, and if that were to happen then of course their response would be considered carefully whilst we figure out the next steps. Given my first paragraph, I’m hopeful that such a communication will not be forthcoming. Finally, it is worth noting, and thanking, the DNSOP WG chairs, Harald, and several members of the IAB, who have helped craft the liaison statement and agree to the approach that is being taken here. Once sent, I will share a pointer to the liaison statement with the DNSOP WG. Hopefully this addresses your questions and concerns. Regards, Rob // Wearing a “Responsible AD for this document only” hat. From: Joe Abley Sent: 07 March 2023 23:48 To: d...@virtualized.org; Rob Wilton (rwilton) Cc: dnsop@ietf.org; draft-ietf-dnsop-alt-...@ietf.org; dnsop-cha...@ietf.org Subject: Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps On Tue, Mar 7, 2023 at 15:56, David Conrad mailto:d...@virtualized.org>> wrote: 4 weeks for ICANN (which? Organization, Board, Community, all 3?) to provide feedback? (That feels sort of like the ITU asking "the IETF" for feedback on an IP-related protocol document in 4 weeks.) Did the IETF (also which?) provide feedback on this similar request for feedback? https://www.icann.org/en/public-comment/proceeding/proposed-procedure-for-selecting-a-top-level-domain-string-for-private-use-13-01-2023 It seems like the answer is no. Perhaps it would be useful for someone to decide whether these ships are intentionally passing in the night or whether more attention to navigation is required. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-alt-tld next steps
Hi, I wanted to thank the WG, chairs, and authors, for their work and patience with me on the alt-tld draft and to let the WG know of the next steps. Warren and Paul have posted an updated -22 version that addresses my AD review comments, and hence I will start a 4-week IETF LC on this version shortly (i.e., hopefully in the next couple of days - as soon as the liaison statement is good to go). Wes, Mirja, and the DNSOP chairs, and Harald have helped me craft a liaison statement to send to ICANN once the LC has started (which will be sent from OPS Area) informing them of the progress of this document, hence also providing an opportunity for comments via the standard IETF LC process. The extended 4-week IETF LC is to ensure that ICANN have enough time to review the document and provide any feedback that they may have. My hope, and expectation, is that the document will then following the standard IETF document approval and publication process. Regards, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AD review of draft-ietf-dnsop-alt-tld-21
Hi Warren, & Paul, Those proposed changes look fine to me, so please can you post an updated version. Regards, Rob From: Warren Kumari Sent: 03 March 2023 23:28 To: Rob Wilton (rwilton) Cc: dnsop@ietf.org; draft-ietf-dnsop-alt-tld@ietf.org Subject: Re: AD review of draft-ietf-dnsop-alt-tld-21 On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton mailto:rwil...@cisco.com>> wrote: Hi authors, WG, Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They are all minor/nit comments, meaning that I'll leave it to the authors discretion as to how they want to handle these comments. Minor level comments: (1) p 3, sec 2. The alt Namespace Groups wishing to create new alternative namespaces may create their alternative namespace under a label that names their namespace under the .alt pseudo-TLD. The .alt namespace is unmanaged. This seems slightly strong given that the ISE draft is planning on setting up a registry somewhere. So, perhaps "The .alt namespace is not managed by the IETF or IANA"? Good point. Here is the original with a bit more text for context: "The .alt namespace is unmanaged. This document does not define a registry or governance model for the .alt namespace." I don't really know if GNU creating a registry really counts at "managing" the .alt namespace, but we can skip that philosophical question by rewording it like so: "This document defines neither a registry nor governance model for the .alt namespace, as it is not managed by the IETF or IANA. " (2) p 3, sec 2. The alt Namespace This document does not define a registry or governance model for the .alt namespace. Developers, applications and users should not expect unambiguous mappings from names to name resolution mechanisms. Is "Developers, applications, users should not expect unambiguous mappings" a bit strong? A possible alternative could be: "Developers, applications and users are not guaranteed to have unambiguous mappings from names to name resolution mechanisms." Hmmm - I'm not sure if it is actually a bit strong, I think that the issue is more that we cannot really tell developers or users to "expect" anything — my auntie might well expect some.name.gns.alt<http://some.name.gns.alt/> to be an unambiguous mapping, and telling her that she shouldn't expect this is silly - she doesn't read RFCs[0] I changed this to "There is no guarantee of unambiguous mappings from names to name resolution mechanisms." ? I removed the "Developers, applications and users" wording as it just opens the question of who should expect this (cats?), or who might be guaranteed anything (chimps?). (3) p 3, sec 2. The alt Namespace Currently deployed projects and protocols that are using pseudo-TLDs may choose to move under the .alt pseudo-TLD, but this is not a requirement. I was wondering whether we could we be slightly stronger here and use "recommended to move" rather than "may choose to move"? I.e., I think that the IETF position could reasonably be that we would like these to all turn up under alt and not squat in the root namespace. This works for me - it's not a requirement, and so people can happily ignore it. Of course, even if it were a requirement, people can still happily ignore it… (https://i.cbc.ca/1.3173445.1438223040!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/winnipeg-blue-bombers.jpg) Nit level comments: (4) p 6, sec Appendix A. Changes / Author Notes. * During AD review, made a few more requested changes As a minor nit, I think that these comments were during the WGLC, rather than AD review. Fair 'nuff, fixed. I also added some additional names to the acknowledgement section - *huge* apologies to anyone we may have missed… Warren. [0]: I know this for a fact, as she doesn't actually exist :-P On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton mailto:rwil...@cisco.com>> wrote: Hi authors, WG, Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They are all minor/nit comments, meaning that I'll leave it to the authors discretion as to how they want to handle these comments. Minor level comments: (1) p 3, sec 2. The alt Namespace Groups wishing to create new alternative namespaces may create their alternative namespace under a label that names their namespace under the .alt pseudo-TLD. The .alt namespace is unmanaged. This seems slightly strong given that the ISE draft is planning on setting up a registry somewhere. So, perhaps "The .alt namespace is not managed by the IETF or IANA"? (2) p 3, sec 2. The alt Namespace This document does not define a registry or governance model for the .alt namespace. Developers, applications and users should not expect unambiguous mappings from names to name resolution mechanisms. Is "Developers, applications, users should not expect unambiguous mappings"
[DNSOP] AD review of draft-ietf-dnsop-alt-tld-21
Hi authors, WG, Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They are all minor/nit comments, meaning that I'll leave it to the authors discretion as to how they want to handle these comments. Minor level comments: (1) p 3, sec 2. The alt Namespace Groups wishing to create new alternative namespaces may create their alternative namespace under a label that names their namespace under the .alt pseudo-TLD. The .alt namespace is unmanaged. This seems slightly strong given that the ISE draft is planning on setting up a registry somewhere. So, perhaps "The .alt namespace is not managed by the IETF or IANA"? (2) p 3, sec 2. The alt Namespace This document does not define a registry or governance model for the .alt namespace. Developers, applications and users should not expect unambiguous mappings from names to name resolution mechanisms. Is "Developers, applications, users should not expect unambiguous mappings" a bit strong? A possible alternative could be: "Developers, applications and users are not guaranteed to have unambiguous mappings from names to name resolution mechanisms." (3) p 3, sec 2. The alt Namespace Currently deployed projects and protocols that are using pseudo-TLDs may choose to move under the .alt pseudo-TLD, but this is not a requirement. I was wondering whether we could we be slightly stronger here and use "recommended to move" rather than "may choose to move"? I.e., I think that the IETF position could reasonably be that we would like these to all turn up under alt and not squat in the root namespace. Nit level comments: (4) p 6, sec Appendix A. Changes / Author Notes. * During AD review, made a few more requested changes As a minor nit, I think that these comments were during the WGLC, rather than AD review. Regards, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] An Orderly Way Forward on Special Use Names (Yes, again)
Hi Ted, I think that it is this one (from the side meeting wiki): Wednesday 9 November Room: Richmond 6 - Wednesday 10:00 6761bis Paul Hoffman (paul.hoff...@icann.org<mailto:paul.hoff...@icann.org>) Discussion of the future of RFC 6761<https://datatracker.ietf.org/doc/rfc6761/> registry; for example, see (https://datatracker.ietf.org/doc/draft-hoffman-rfc6761bis/) Zoom link<https://us02web.zoom.us/j/83413016917?pwd=UkVUc0ZtTzdjKzVKOUNzeUYvcVE3dz09> Meeting ID: 834 1301 6917, Passcode: test-onion I presume that Paul will correct me if I’m pointing you to the wrong thing. Regards, Rob From: Ted Lemon Sent: 07 November 2022 12:25 To: Rob Wilton (rwilton) Cc: Paul Hoffman ; dnsop Subject: Re: [DNSOP] [Ext] An Orderly Way Forward on Special Use Names (Yes, again) I haven't seen an announcement about this side meeting yet. Did I miss it? On Wed, Oct 19, 2022 at 2:21 PM Rob Wilton (rwilton) mailto:40cisco@dmarc.ietf.org>> wrote: Replying here only because it is a convenient place in this thread, and definitely not with any hats on. I think that a side meeting specifically to discuss how to progress RFC 6761bis at IETF 115 could be a good way forward. I also note that the final agenda for IETF 115 is available and side meetings can be booked. Personally, I'm less keen on either spinning up a separate WG to tackle this or going via the AD-sponsored path because it isn't obvious that an AD-sponsored bis document would gain IETF consensus when the chartered WG is unable to. The other suggestion that I wanted to put out there is perhaps a small, dedicated design team within DNSOP set up by the chairs to work on this problem and collectively work on a solution draft that can then be brought back to the WG. In my experience, sometimes issues that get stuck within a larger WG end up making more progress when worked on within a smaller team. Regards, Rob > -Original Message- > From: DNSOP mailto:dnsop-boun...@ietf.org>> On Behalf > Of Paul Hoffman > Sent: 04 October 2022 00:06 > To: Warren Kumari mailto:war...@kumari.net>> > Cc: dnsop mailto:dnsop@ietf.org>> > Subject: Re: [DNSOP] [Ext] An Orderly Way Forward on Special Use Names (Yes, > again) > > On Oct 3, 2022, at 3:53 PM, Warren Kumari > mailto:war...@kumari.net>> wrote: > > As the chairs’ email also said: > > “We’re well aware not everyone is interested in this work and that the WG > has a chronic issue of a full pipeline of documents to consider.” A side > meeting > to discuss the followup to RFC8244 may provide some energy to work on the > problem. > > The chairs' message did not talk about "the followup to RFC8244". When I > volunteered to set up the side meeting, I assumed it was about RFC 6761. I do > not see any reason to follow up on the comprehensive list in RFC 8244; it > stands > well on its own. > > > It is very unclear that a different WG would attract sufficient mass - yes, > many people in DNSOP are tired of this topic, but it is clearly an important > topic (and in the DNSOP charter), and moving it off to a group where it > doesn’t > get the required review is not helpful. > > The logic here concerns me. If a different WG cannot attract sufficient mass, > discussing it in DNSOP with that same insufficient mass wastes many more > people's time. An insufficient mass is a strong indicator that something > cannot > reach IETF consensus; that is important information. > > The fact that it is currently in the DNSOP charter is not terribly relevant: > it was > put there when we were young and hopeful. We then let it fester in the denial > zone, mouldering until (ed: stop with the gross imagery!)... > > --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi David, Thanks, again with no hats, except for my comment on the first question. Please see inline … From: David Conrad Sent: 23 October 2022 20:01 To: Rob Wilton (rwilton) Cc: dnsop@ietf.org Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? Rob, On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton) mailto:rwil...@cisco.com>> wrote: As I read it, the partitioning of the domain name namespace is really to achieve two aims: On this mailing list, I think there is a pretty good understanding of the intent of .alt and I don’t think there is much in the way of disagreement on that intent. As far as I can tell, the points of contention are: 1. whether the IETF “reserving” a TLD is intruding on ICANN’s territory. RW: With a “responsible AD for this document hat on”, I would like to ask the WG to consider this question as being out of scope for the moment, and assume that this work is within the scope of the IETF. 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. 1. whether there will be a registry of .alt uses (i.e., non-DNS name resolution systems) and if so, who will operate that registry. RW: The document should only define a registry of .alt uses if the registry is managed by IANA. 3) whether the inevitable leakage of .alt queries to the DNS represent potential issues, and if so, should there be an effort to address those issues. RW: I’ll defer answering that one to the experts, on which I am not one. FWIW, my views: 1) Ask the stupid question. 2) A voluntary, lightweight registry operated by IANA can help developers avoid collision. 3) Identifying leakage to the DNS as a protocol violation can, over time, help reduce that leakage. This is outside my area of expertise, but I'm not convinced that the global DNS would see any significant increase in load, because the stub resolver would generally not be sending the requests to the DNS assuming that they are valid domains, and if they are not valid domains then that would seem to be the same as what DNS already handles today. The root of the DNS is a commons, supported by volunteers who are paying out of their own pocket to provision a global infrastructure. I’m personally not comfortable recommending techniques that can add undefined (could be minimal, might not be: no one knows for sure) load to that infrastructure. If you look at the ICANN OCTO web page Paul referenced earlier (https://magnitude.research.icann.org) and filter for “special use” TLDs, you’ll see data related to the number of queries received. Some of those (e.g., .local) are non-trivial and, in my opinion, are indications of brokenness that should be fixed — the root shouldn’t be seeing those queries. My suggestion of using RFC 2119 “MUST NOT” language (i.e., queries for names in .alt MUST NOT be sent to the root server system supported by IANA) is in an effort to discourage an increase in that query volume over time. RW: If this is a general problem for “special use” TLDs then it would be better to have a separate document that handles those consistently and generically rather than creating a new rule specifically for .alt domains. It seems obvious to me that if a namespace is explicitly defined to not be in the DNS, embedding a reliance on the DNS would be a protocol violation. I am actually surprised that this would be controversial. And as for the eavesdropping concern, doesn't this equally apply for all domain lookups, particularly invalid ones? As I’m sure you’re aware, by default, DNS is plain text. If a non-DNS name resolution protocol is specified to not be plain text (presumably any new protocol would be encrypted), then users of that protocol have an expectation that their queries are protected. By falling back to DNS, that expectation is silently violated. RW: This is a reasonable point to consider, even though it also feels like the world may end up moving to DoH, or DoQ fairly quickly. Personally, I think that it is somewhat hard for users to have that general expectation if the name resolution is using a combination of name resolution protocols (including unencrypted DNS). Regards, Rob Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi David, [Still with no hats] > -Original Message- > From: David Conrad > Sent: 22 October 2022 17:40 > To: Rob Wilton (rwilton) > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? > > Rob, > > On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) wrote: > > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard? > > The draft says “Informational”. It is (maybe) recommending the partitioning > of > the domain name namespace, explicitly creating a sub-space that is for non- > DNS use. It makes no sense to me to then pretend it’s "just fine” to issue > DNS > queries in that sub-namespace. As I read it, the partitioning of the domain name namespace is really to achieve two aims: 1) to guarantee that .alt, and no domains under .alt, will ever exist in the DNS, and hence it will need be impossible for an alternative name resolution system to "shadow" valid .alt entries in the DNS (since there can be none). 2) it gives a place to experiment with alternative naming systems in a way that doesn't interfere with the DNS. As I understand it , some of these alternative name services are squatting on unallocated TLDs, and some browsers are resolving names in these alternative name services. This is not ideal, particularly if those unallocated TLDs end up getting sold by ICANN to companies that expect to use them with the regular DNS rather than any alternative name service. > > > My interpretation of Paul's comment is that nothing bad happens if a client > does attempt to resolve .alt names in the DNS because they will just fail in > the > same way as any other domain that doesn't exist in the DNS, and that is okay. > > But it is not OK. Yes, the root servers are surely provisioned to handle the > additional load the use of .alt might create, but it adds to the useless > noise — > why would the IETF encourage this? Worse, it exposes .alt traffic to > potential > eavesdroppers. I’m confused why the IETF would publish an informational > document that says both of those are not protocol violations. My assumption is that a browser, application, or even the OS, that supports any of these alternative name resolution services will have some code switch that decides to either look up the name in the DNS or look the name up in the alternative service. E.g., If my browser supports GNS, then the browser knows to try and resolve https://myfunkyname.gns.alt/ using GNS. If the browser has the code to do that, then I would also hope then it wouldn't also try and resolve the same domain in the DNS on failure to resolve it using GNS. But even if they did, I don't see that as really being a problem, it will just fail the same way as any other unknown domain. If a user types the same URL into a different browser that doesn’t support GNS, then stub resolver would naturally try and resolve https://myfunkyname.gns.alt/ in the DNS, which must fail because there can never be any domains in the DNS that end with .alt. It fails in the same way as if I mistype a URL and try and resolve "https:://google.con" rather than "https://google.com;. But I don't understand why this alternative browser, that doesn't care about alternative name resolution schemes at all, must change their code. This is outside my area of expertise, but I'm not convinced that the global DNS would see any significant increase in load, because the stub resolver would generally not be sending the requests to the DNS assuming that they are valid domains, and if they are not valid domains then that would seem to be the same as what DNS already handles today. And as for the eavesdropping concern, doesn't this equally apply for all domain lookups, particularly invalid ones? Regards, Rob > > > Possibly, the draft could have some text that allows stub resolves to > > filter out > DNS requests for .alt names if they wish. > > The point is that DNS resolvers of any kind are explicitly not supposed to see > .alt queries — .alt is NOT a DNS namespace. If they do (and they obviously > will), something is broken and should be fixed. > > Regards, > -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Possible alt-tld last call?
Hi David, If this was a MUST NOT, then at the point that the RFC is published, would that not mean that all DNS stub (and maybe recursive) resolvers immediately become non complaint with the new standard? E.g., if I try and access https://somedomain.alt in my browser today then it attempts to lookup the domain and fails because it doesn't exist. My interpretation of Paul's comment is that nothing bad happens if a client does attempt to resolve .alt names in the DNS because they will just fail in the same way as any other domain that doesn't exist in the DNS, and that is okay. Possibly, the draft could have some text that allows stub resolves to filter out DNS requests for .alt names if they wish. I.e., filtering does no harm, performing the DNS lookup also does no harm, and the implementations can decide if they want to add a special code path for this case or just follow the standard code path. Regards, Rob // No hats. // Also not a DNS expert, so apologies if I'm using the wrong terms/words ... > -Original Message- > From: DNSOP On Behalf Of David Conrad > Sent: 22 October 2022 00:55 > To: Paul Hoffman > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] [Ext] Possible alt-tld last call? > > Paul, > > On Oct 21, 2022, at 3:34 PM, Paul Hoffman > wrote: > >> If the intent here is that .alt names should never be looked up via the > DNS, then MUST NOT is the expected behavior, no? > > There is no such intent of the draft. > > Ah. Then I guess I don’t support the draft and the rest of my input is > irrelevant. > > Regards, > -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] An Orderly Way Forward on Special Use Names (Yes, again)
Replying here only because it is a convenient place in this thread, and definitely not with any hats on. I think that a side meeting specifically to discuss how to progress RFC 6761bis at IETF 115 could be a good way forward. I also note that the final agenda for IETF 115 is available and side meetings can be booked. Personally, I'm less keen on either spinning up a separate WG to tackle this or going via the AD-sponsored path because it isn't obvious that an AD-sponsored bis document would gain IETF consensus when the chartered WG is unable to. The other suggestion that I wanted to put out there is perhaps a small, dedicated design team within DNSOP set up by the chairs to work on this problem and collectively work on a solution draft that can then be brought back to the WG. In my experience, sometimes issues that get stuck within a larger WG end up making more progress when worked on within a smaller team. Regards, Rob > -Original Message- > From: DNSOP On Behalf Of Paul Hoffman > Sent: 04 October 2022 00:06 > To: Warren Kumari > Cc: dnsop > Subject: Re: [DNSOP] [Ext] An Orderly Way Forward on Special Use Names (Yes, > again) > > On Oct 3, 2022, at 3:53 PM, Warren Kumari wrote: > > As the chairs’ email also said: > > “We’re well aware not everyone is interested in this work and that the WG > has a chronic issue of a full pipeline of documents to consider.” A side > meeting > to discuss the followup to RFC8244 may provide some energy to work on the > problem. > > The chairs' message did not talk about "the followup to RFC8244". When I > volunteered to set up the side meeting, I assumed it was about RFC 6761. I do > not see any reason to follow up on the comprehensive list in RFC 8244; it > stands > well on its own. > > > It is very unclear that a different WG would attract sufficient mass - yes, > many people in DNSOP are tired of this topic, but it is clearly an important > topic (and in the DNSOP charter), and moving it off to a group where it > doesn’t > get the required review is not helpful. > > The logic here concerns me. If a different WG cannot attract sufficient mass, > discussing it in DNSOP with that same insufficient mass wastes many more > people's time. An insufficient mass is a strong indicator that something > cannot > reach IETF consensus; that is important information. > > The fact that it is currently in the DNSOP charter is not terribly relevant: > it was > put there when we were young and hopeful. We then let it fester in the denial > zone, mouldering until (ed: stop with the gross imagery!)... > > --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Possible alt-tld last call?
does not indicate any IETF endorsement of entries in the registry or the referenced specifications (although I think that this is probably generally a given for IANA registries anyway), and (ii) nor does the registry make any guarantees that it is necessary complete. 2. I would recommend a registration policy of “Specification required”. Specifically, the definition of specification required automatically includes expert review, and RFC 8126 already allows appeals to the IESG/IAB for rejected registrations. 3. There should be documented guidelines of what the expert review part of the “Specification Required” policy should entail: * The specification needs to be for a name resolution system and be documented in a stable reference (as per RFC 8126). * The expert reviewer may, but is not required, validate the quality or correctness of the specification. The expert reviewer may reject requests where the specification is insufficient. * Name resolution protocols are expected to only require a single entry, or otherwise a very small number of unique entries, directly under .alt. * Name resolution protocols SHOULD choose a unique name under .alt, but the expert reviewer MAY allow multiple entries under .alt in exceptional circumstances. Proposed next steps (for authors, WG, and WG chairs to consider): I think that it would be helpful for the authors to post an updated version of the draft aiming to incorporate the feedback that has been received recently. I also suggest that it would be helpful to have discussion this draft in DNSOPS in IETF 115, if there is time available. It is up to the authors & WG chairs, but it may be useful to do a hum or “show of hands” on test consensus (specifically if anyone can’t live with) on the proposals for: 4(i), and 4(iii) above. I am, of course, happy to receive comments from the DNSOP WG (or chairs, or authors) on the mailing list on any aspect of my comments above, either stating that the proposals are awful/misguided/wrong/etc, or that they could be an acceptable way forward. But I would really appreciate it if we can try and compromise a little to find a way forward. Kind regards, Rob From: DNSOP On Behalf Of Suzanne Woolf Sent: 16 October 2022 16:03 To: dnsop@ietf.org Cc: Rob Wilton (rwilton) ; DNSOP-Chairs Chairs Subject: [DNSOP] Possible alt-tld last call? Dear Colleagues, The chairs have gotten a couple of requests, off-list and on, for a WGLC on draft-ietf-dnsop-alt-tld. We’ve reviewed the current draft closely and have some concerns that we feel need to be resolved before any effort to move the draft forward. (Suzanne wrote this but it’s been discussed among all of the co-chairs.) 1. As far as I can tell, this draft does not comply with RFC 6761. This is a problem for two reasons. First, this creates a process problem in that RFC 6761 is the standards-track document that specifies how the SUDN registry is to be administered, so a request that doesn’t meet the requirements in 6761 can’t (or at least shouldn’t) go into the registry. RFC 6761 section 4 asserts: The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied. The alt-tld draft ignores this MUST, without explanation (unless I missed it). The substantive issue is that the questions in Section 5 are there to make sure there’s a full description of the expected handling of a proposed name by the assorted components that take part in DNS operations and protocol. The draft answers at least some of the Section 5 questions, but the answers are largely implied. For example, the draft says that DNS resolvers seeing .alt names "do not need to look them up in the DNS context”, but a big part of the point of codifying these names is the assumption that queries will leak and DNS servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is simply not in the public DNS root zone and the root servers (or better yet, any intermediate resolver) should answer “name error”/NXDOMAIN for such queries. But this should probably be said explicitly, because people who configure DNS servers and services shouldn’t have to guess what’s being implied here. (The WG discussed the possibility that such queries should be blackholed and not answered at all, which is in some ways an obvious answer. Clarification of why this was discarded might also be helpful.) So, the current draft isn’t meeting the requirements for the registry, and also doesn’t clearly answer substantive questions about what DNS operators are expected to do. This makes me uncomfortable doing a WGLC without a new rev. It would be Rob Wilton’s call of course (as AD for this draft, substituting for Warren) but I’m really uneasy with a WGLC without those changes— they seem rather too large to punt for a post-WGLC versi
Re: [DNSOP] Possible alt-tld last call?
Hi Joe, > -Original Message- > From: Joe Abley > Sent: 16 October 2022 20:30 > To: Brian Dickson > Cc: Eliot Lear ; Rob Wilton (rwilton) ; > Suzanne Woolf ; dnsop@ietf.org; DNSOP-Chairs Chairs > > Subject: Re: [DNSOP] Possible alt-tld last call? > > Op 16 okt. 2022 om 15:03 heeft Brian Dickson > het volgende geschreven: > > > For example, using a hash function, such as sha2-256, with output encoded > as base32hex. > > (This is just an example; any suitable function that takes URI as input and > produces an ASCII DNS-compatible label as output would suffice.) > > If we start from the position that names in this shared namespace don't need > to be semantically meaningful to humans then this whole problem space > becomes a whole lot easier, or perhaps doesn't even rise to the level of > "problem". See also 98% of the work done by the ICANN community and > arguably the entire business models of registries and registrars. > > However, I don't think we are starting from that position. For example we > hear there is demand for .giraffe for the giraffe naming system described at > https://giraffe.org/ because using giraffe.org as an anchor for that naming > system in the namespace is not acceptable to anybody who cares about GNS. > > If giraffe.org doesn't cut the mustard then I have my doubts that > jduxbenebrnjxudnxznbrnr.alt will satisfy anybody either. > > (If giraffe.org can't be tolerated then I also don't see why giraffe.alt is an > obvious solution, but I sense people are tired of hearing me say that so I'll > leave it this parenthetical cloak of invisibility and continue whistling > innocently.) You may be right, but I don't think that we can really know this unless we try. And at least if we did standardize .alt then we are offering a sanctioned mechanism for supporting alternative domain resolution systems. I think that we know that gns is willing to use .alt, so we have at least one taker. Rob // No hats. > > > Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld
Hi Roy, WG, Roy, just for clarity, am I right to presume that the status of the document that you propose would purely be informational? It is, of course, up to the WG to decide what to do with this document, but I would like to make a couple of comments that may help the WG. I would like to somewhat echo a point that was made in DNSOP yesterday when this draft was being discussed, in that I don't believe that IETF should publish a document that either directly or indirectly undermines ISO TC46's ownership or authority over the ISO3166 code points. I believe that this concern is likely shared by other ADs. Hence, if the WG decides to progress this document with the proposed structure below, then I'm not convinced that just documenting that these code points exist and that some people use them would be sufficient. Given the informal liaison feedback that was received, I think that the IETF would likely need to adopt stronger wording that proactively recommends that these country codes are not used for private networks, and highlights the potential problems with doing so. Regards, Rob // Ops AD -Original Message- From: DNSOP On Behalf Of Roy Arends Sent: 30 July 2021 19:21 To: dnsop Subject: [DNSOP] Moving forward on draft-ietf-dnsop-private-tld Dear WG About 40 years ago, give or take, when Jon Postel planned to use the ISO3166 two character code elements as top level domains representing country names, ISO's TC46 secretariat was contacted (as was requested to users of the ISO3166 standard at the time) and he was told that the standard should not be used for DNS, as the future was in X.500. (Postel wasn’t swayed by the argument, and did what we now refer to as permission-less innovation). Recently, the ISO was contacted again, and subsequently the WG was again told that the standard wasn’t to be used in this way. It seems that a handful of folks are swayed by the argument and want to use this as guidance for the future of draft-ietf-dnsop-private-tld. Early on, Joe Abley proposed a way forward that I held off initially: Recognise that User Assigned 3166 code elements are used in various ways, including private networks, that these elements have not been delegated and are known to be used to anchor private namespaces. Do not recommend, promote or reserve anything, no registries. Document potential future pitfalls for using these codes for private namespaces and empower readers to make their own decisions. I now see that with the current status quo, this might a way forward that both sides of the argument might come together on. Essentially, instead of making the pond safe, we’ll have a warning sign that using the pond is at their own risk. I hope the WG can come together on this as a way forward. Warmly, Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Mapping IANA deprecated to YANG status deprecated [was RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)]
Discuss cleared. Thanks all for accommodating. Regards, Rob > -Original Message- > From: Ladislav Lhotka > Sent: 17 June 2021 07:24 > To: Warren Kumari ; Benno Overeinder > > Cc: Rob Wilton (rwilton) ; dnsop@ietf.org; dnsop- > cha...@ietf.org; draft-ietf-dnsop-iana-class-type-y...@ietf.org; The IESG > ; Paul Wouters ; michelle.cot...@iana.org > Subject: Re: [DNSOP] Mapping IANA deprecated to YANG status deprecated > [was RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: > (with DISCUSS and COMMENT)] > > Warren Kumari writes: > > > Thank you all. > > > > Having heard no objections, we will go with Rob's proposed text. > > > > Lada / Petr, please fold in this change, and then poke me LOUDLY and I'll > > hit the "Go!" button... > > Done in -05. > > Thanks, Lada > > > > > Thanks all, > > W > > > > On Wed, Jun 16, 2021 at 7:00 AM Benno Overeinder > wrote: > > > >> Thank you Rob. > >> > >> I am the document shepherd, but reply with no hats. > >> > >> I understand the concern, and I am fine with the proposed change. > > > > > >> Best, > >> > >> -- Benno > >> > >> > >> On 10/06/2021 18:05, Rob Wilton (rwilton) wrote: > >> > Hi DNS Ops, > >> > > >> > Warren, Lada and I discussed this further today. Warren and I think > >> that mapping IANA deprecated to YANG deprecated is the right behaviour > >> here, and Lada is fine with either outcome. > >> > > >> > The main concern of mapping from IANA 'deprecated' to YANG 'status > >> obsolete' is that it would force a hard transition if any DNS classes or > >> RR's ever needed to be deprecated. I.e., when a server picks up a new > >> version of the generated YANG types file it would be obliged to > immediately > >> remove support for the 'status obsolete' definition with no grace period > >> and no option to continue using it (RFC 7950 describes this is a SHOULD > >> NOT, but this constraint is effectively stronger in the versioning related > >> drafts currently progressing in the NETMOD WG). > >> > > >> > So, the following change is proposed: > >> > > >> > OLD: > >> > "status": Include only if a class or type registration has been > >> > deprecated or obsoleted. In both cases, use the value "obsolete" > >> > as the argument of the "status" statement. > >> > > >> > NEW: > >> > "status": Include only if a class or type registration > >> has been > >> > deprecated or obsoleted. IANA "deprecated" maps to YANG > >> > status "deprecated", and IANA "obsolete" maps to YANG status > >> > "obsolete". > >> > > >> > Does anyone in the WG strongly object to this change? If so, please let > >> us know by Wed's 16th. > >> > > >> > Regards, > >> > Rob > >> > > >> > > >> >> -Original Message- > >> >> From: Ladislav Lhotka > >> >> Sent: 10 June 2021 12:37 > >> >> To: Rob Wilton (rwilton) ; The IESG > ; > >> >> Warren Kumari ; michelle.cot...@iana.org > >> >> Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; > >> dnsop-cha...@ietf.org; > >> >> dnsop@ietf.org; be...@nlnetlabs.nl > >> >> Subject: RE: Robert Wilton's Discuss on > >> draft-ietf-dnsop-iana-class-type-yang- > >> >> 03: (with DISCUSS and COMMENT) > >> >> > >> >> "Rob Wilton (rwilton)" writes: > >> >> > >> >>> Hi Lada, > >> >>> > >> >>> I've also copied Michelle on - since I think that it would be helpful > >> for IANA > >> >> to at least be aware of this discussion. > >> >>> > >> >>> Sorry for being slow to get back to you. I've expanded on my discuss > >> >> comment below, but it may be helpful for you, Warren, I, possibly > >> Michelle, > >> >> to have a quick chat to see if we can resolve it. > >> >>> > >> >>> > >> >>> > >> >>>> -Original Message- > >> >>>> From: Ladislav Lhotka > >> >>>> Sent: 03 June
[DNSOP] Mapping IANA deprecated to YANG status deprecated [was RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)]
Hi DNS Ops, Warren, Lada and I discussed this further today. Warren and I think that mapping IANA deprecated to YANG deprecated is the right behaviour here, and Lada is fine with either outcome. The main concern of mapping from IANA 'deprecated' to YANG 'status obsolete' is that it would force a hard transition if any DNS classes or RR's ever needed to be deprecated. I.e., when a server picks up a new version of the generated YANG types file it would be obliged to immediately remove support for the 'status obsolete' definition with no grace period and no option to continue using it (RFC 7950 describes this is a SHOULD NOT, but this constraint is effectively stronger in the versioning related drafts currently progressing in the NETMOD WG). So, the following change is proposed: OLD: "status": Include only if a class or type registration has been deprecated or obsoleted. In both cases, use the value "obsolete" as the argument of the "status" statement. NEW: "status": Include only if a class or type registration has been deprecated or obsoleted. IANA "deprecated" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status "obsolete". Does anyone in the WG strongly object to this change? If so, please let us know by Wed's 16th. Regards, Rob > -----Original Message- > From: Ladislav Lhotka > Sent: 10 June 2021 12:37 > To: Rob Wilton (rwilton) ; The IESG ; > Warren Kumari ; michelle.cot...@iana.org > Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; dnsop-cha...@ietf.org; > dnsop@ietf.org; be...@nlnetlabs.nl > Subject: RE: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang- > 03: (with DISCUSS and COMMENT) > > "Rob Wilton (rwilton)" writes: > > > Hi Lada, > > > > I've also copied Michelle on - since I think that it would be helpful for > > IANA > to at least be aware of this discussion. > > > > Sorry for being slow to get back to you. I've expanded on my discuss > comment below, but it may be helpful for you, Warren, I, possibly Michelle, > to have a quick chat to see if we can resolve it. > > > > > > > >> -Original Message- > >> From: Ladislav Lhotka > >> Sent: 03 June 2021 14:17 > >> To: Rob Wilton (rwilton) ; The IESG > >> Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; dnsop-cha...@ietf.org; > >> dnsop@ietf.org; be...@nlnetlabs.nl > >> Subject: Re: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type- > yang- > >> 03: (with DISCUSS and COMMENT) > >> > >> Hi Rob, > >> > >> On 03. 06. 21 13:16, Robert Wilton via Datatracker wrote: > >> > >> ... > >> > >> > -- > >> > DISCUSS: > >> > -- > >> > > >> > Hi, > >> > > >> > One issue that I think we should should discuss and resolve (sorry for > the > >> late > >> > discuss ballot): > >> > > >> > In section 4, it states: > >> > > >> >"status": Include only if a class or type registration has been > >> > deprecated or obsoleted. In both cases, use the value "obsolete" > >> > as the argument of the "status" statement. > >> > > >> > I know that we have had some previous discussion on this on Netmod, > but, > >> if > >> > draft-ietf-netmod-yang-module-versioning-02 gets standardized then it > will > >> > effectively evolve YANG's "status deprecated" into "must implement or > >> > explicitly deviate" and YANG's "status obsolete" into "must not > implement". > >> It > >> > wasn't clear to me that marking one of these fields as being deprecated > in > >> an > >> > IANA registry would mean that existing implementations must stop > using it > >> if > >> > they migrate to a new version of the generated YANG module. Hence, I > >> think > >> > that at this stage, it may be safer to map IANA "deprecated" into YANG's > >> > "status deprecated"? > >> > > >> > >> Yes, this was discussed repeatedly in NETMOD and DNSOP WGs. I think > we > >> currently have to use RFC 7950 for the status definitions, and so in YANG > >> > >>o "deprecated" indic
Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang-03: (with DISCUSS and COMMENT)
Hi Lada, I've also copied Michelle on - since I think that it would be helpful for IANA to at least be aware of this discussion. Sorry for being slow to get back to you. I've expanded on my discuss comment below, but it may be helpful for you, Warren, I, possibly Michelle, to have a quick chat to see if we can resolve it. > -Original Message- > From: Ladislav Lhotka > Sent: 03 June 2021 14:17 > To: Rob Wilton (rwilton) ; The IESG > Cc: draft-ietf-dnsop-iana-class-type-y...@ietf.org; dnsop-cha...@ietf.org; > dnsop@ietf.org; be...@nlnetlabs.nl > Subject: Re: Robert Wilton's Discuss on draft-ietf-dnsop-iana-class-type-yang- > 03: (with DISCUSS and COMMENT) > > Hi Rob, > > On 03. 06. 21 13:16, Robert Wilton via Datatracker wrote: > > ... > > > -- > > DISCUSS: > > -- > > > > Hi, > > > > One issue that I think we should should discuss and resolve (sorry for the > late > > discuss ballot): > > > > In section 4, it states: > > > >"status": Include only if a class or type registration has been > > deprecated or obsoleted. In both cases, use the value "obsolete" > > as the argument of the "status" statement. > > > > I know that we have had some previous discussion on this on Netmod, but, > if > > draft-ietf-netmod-yang-module-versioning-02 gets standardized then it will > > effectively evolve YANG's "status deprecated" into "must implement or > > explicitly deviate" and YANG's "status obsolete" into "must not implement". > It > > wasn't clear to me that marking one of these fields as being deprecated in > an > > IANA registry would mean that existing implementations must stop using it > if > > they migrate to a new version of the generated YANG module. Hence, I > think > > that at this stage, it may be safer to map IANA "deprecated" into YANG's > > "status deprecated"? > > > > Yes, this was discussed repeatedly in NETMOD and DNSOP WGs. I think we > currently have to use RFC 7950 for the status definitions, and so in YANG > >o "deprecated" indicates an obsolete definition, but it permits > new/continued implementation in order to foster interoperability > with older/existing implementations. > > This is incompatible with the meaning of "deprecated" in IANA > registries, which is per RFC 8126: "use is not recommended". I don't think that there is a perfect answer here, and I think that for the moment we are looking for the least bad option. The YANG and IANA definitions of deprecated are obviously different, but it isn't clear to me how different they actual are from those definitions. E.g., in neither case do they indicate why they are going away (e.g., because they are no longer used, or there is a better way, or there is a security issue). I would also argue that "use is not recommended" applies to the YANG "deprecated" as well, and generally matches what I understand what deprecated means. But ultimately there are two choices here: (1) Map both IANA deprecated and obsolete to YANG obsolete as your draft proposes. If the text in draft-ietf-netmod-yang-module-versioning-02 gets standardized then this means that there will be no way to indicate a DNS class type that shouldn't be used anymore and is going away. Either it is "current" and can/should be implemented, or it is "obsolete" and it cannot be used once the server pulls in the new revision of the types YANG file. I.e., there isn't even a mechanism to deviate it to indicate that it is still supported, there is no possible transition window. (2) Map IANA deprecated -> YANG deprecated. IANA obsolete -> YANG obsolete. With vanilla RFC 7950, the server may or may not implement the deprecated value, and it can use a deviation to be explicit. If draft-ietf-netmod-yang-module-versioning-02 gets standardized: The server is expected to implement it or use a deviation. I.e., there is still a mechanism to allow a server to implement if they need to, but equally they can also choose not to implement it. I'm still of the opinion that (2) is the least bad option out of the two above. A third possibility, a variant of (2), would be to map IANA deprecated to YANG deprecated, but also update the type description to indicate that "Per the IANA [XXX] definition of 'deprecated', use is not recommended. New implementation should not use it; existing implementations should phase out support for it." > > I agree that this discrepancy should be solved
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)
Hi Peter, > -Original Message- > From: Peter van Dijk > Sent: 18 May 2021 18:26 > To: Rob Wilton (rwilton) ; The IESG > Cc: draft-ietf-dnsop-nsec-...@ietf.org; dnsop-cha...@ietf.org; > dnsop@ietf.org; tjw.i...@gmail.com > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop- > nsec-ttl-04: (with COMMENT) > > Hello Rob, > > On Tue, 2021-05-18 at 08:04 -0700, Robert Wilton via Datatracker wrote: > > -- > > COMMENT: > > -- > > > > Hi, > > > > Thanks for this document. > > > > Regarding: > > > > 3.4. Updates to RFC8198 > > > >[RFC8198] section 5.4 (Consideration on TTL) is completely replaced > >by the following text: > > > >| The TTL value of negative information is especially important, > >| because newly added domain names cannot be used while the negative > >| information is effective. > >| > >| Section 5 of [RFC2308] suggests a maximum default negative cache > >| TTL value of 3 hours (10800). It is RECOMMENDED that validating > >| resolvers limit the maximum effective TTL value of negative > >| responses (NSEC/NSEC3 RRs) to this same value. > >| > >| A resolver that supports aggressive use of NSEC and NSEC3 MAY > >| limit the TTL of NSEC and NSEC3 records to the lesser of the > >| SOA.MINIMUM field and the TTL of the SOA in a response, if > >| present. It MAY also use a previously cached SOA for a zone to > >| find these values. > > > > I'm not a DNS expert, and this is just a non binding comment, but I was > > wondering why it is only "MAY" limit the TTL on NSEC and NSEC3 records > to the > > lesser of the SOA.MINIMUM field and the TTL of the SOA in a response > rather > > than a "SHOULD". > > Thank you for your comment. > > The old text was this: > > > A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce > the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the > authority section of a negative response, if SOA.MINIMUM is smaller. > > but this text did nothing (this is also noted in section 1 of the draft), > as signers/authoritatives already took that TTL from the SOA.MINIMUM field > - which this document corrects. > > Furthermore, during WG discussion we realised that in many cases, a > validator handling NSEC/NSEC3 records would not have access to the > relevant SOA at all - for example, in wildcard responses. 'SHOULD' is > quite strong language for something that often is not even possible. [RW] I agree. > > And, finally, the MAY you ask about is behaviour that is only useful in > validators until signers/authoritatives become compliant with this draft. > It is a secondary measure (that the WG explicitly requested so as to > attempt to solve the problem in multiple places) that should become > irrelevant as signers (most of which already have software fixes pending, > merged, or released) get upgraded. > > I hope this answers your question; please let me know if not. [RW] I think so, or at least I'm happy to defer to the WG's judgement here. Thanks for the explanation. Regards, Rob > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)
Hi Donald, > -Original Message- > From: Donald Eastlake > Sent: 17 December 2020 18:00 > To: Rob Wilton (rwilton) > Cc: The IESG ; draft-ietf-dnsop-server-cook...@ietf.org; > dnsop-chairs ; ; > Tim Wicinski > Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-server- > cookies-04: (with COMMENT) > > Hi, > > On Thu, Dec 17, 2020 at 6:50 AM Robert Wilton via Datatracker > wrote: > > > > Robert Wilton has entered the following ballot position for > > draft-ietf-dnsop-server-cookies-04: No Objection > > > > ... > > > > -- > > COMMENT: > > -- > > > > Hi, > > > > Thanks for this document, I found it easy to read. I have a couple of > minor > > questions/comments related to the lifecycles. > > > > Section 3: > > > >Except for when the Client IP address changes, there is no need to > >change the Client Cookie often. It is reasonable to change the > >Client Cookie then only if it has been compromised or after a > >relatively long period of time such as no longer than a year. Client > >Cookies are not expected to survive a program restart. > > > > It isn't clear to me why it is necessary to put an upper bound a on when > a > > client cookie needs to be changed at all. What is the benefit of > changing the > > client cookie once a year? > > This is normal crypto hygiene. It is unsafe to trust a key/cookie > forever. Sooner or later it will get compromised by loss, accident, > whatever. Given this, an upper bound needs to be recommended. If it > were up to me, I would have said a month and that is in fact what it > says in RFC 7873 as follows: > >The longer a secret is used, the higher the probability that it has >been compromised. Thus, clients and servers are configured with a >lifetime setting for their secret, and they roll over to a new secret >when that lifetime expires, or earlier due to deliberate jitter as >described below. The default lifetime is one day, and the maximum >permitted is one month. To be precise and to make it practical to >stay within limits despite long holiday weekends, daylight saving >time shifts, and the like, clients and servers MUST NOT continue to >use the same secret in new requests and responses for more than >36 days and SHOULD NOT continue to do so for more than 26 hours. > > Of course how often to change is a judgement call on which opinions will > differ. [RW] Yes, the explanation above all makes sense. But this is also why a year seems like a strange limit to me: It is long enough that it doesn't seem to offer any great practical benefits, assuming both that it is bad practice to allow it to be compromised for a long time, and also that we care if it has been compromised. Conversely, it is also long enough that it seems like implementations are more likely to be buggy (or not bother at all). Suddenly things stop working after a year and nobody knows why, so they reboot the system and magically the problem goes away again for another year. So, if this should be changed periodically, and it is easy and low impact to do so, then it would seem to make sense for it to change more frequently, say once a week? It seems like my PC wants me to reboot for security updates every week or two anyway ... Regards, Rob > > Assuming you do plan to change it periodically, another consideration > is operational. Say security considerations would mean you should > change it at least every 5 years. What is the chance that, after five > years, anyone will even remember to do it or even remember how to do > it? So the interval should be short enough that operational experience > is kept up. > > Thanks, > Donald > = > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 33896 USA > d3e...@gmail.com > > > 5. Updating the Server Secret > > > > I think that it would be useful to remind the reader that server secrets > are > > expected to be updated on a semi-regular basis, as described in section > 4. > > > > Regards, > > Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Hi Duane, That looks good. Thanks for accommodating. Regards, Rob > -Original Message- > From: iesg On Behalf Of Wessels, Duane > Sent: 14 October 2020 13:35 > To: Rob Wilton (rwilton) > Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski > ; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG > > Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone- > digest-12: (with COMMENT) > > > > > On Oct 12, 2020, at 8:56 AM, Rob Wilton (rwilton) > wrote: > > > > > > > >> > >>> > >>> 2. The ZONEMD Resource Record > >>> > >>> It is > >>> RECOMMENDED that a zone include only one ZONEMD RR, unless the > >> zone > >>> publisher is in the process of transitioning to a new Scheme or > >> Hash > >>> Algorithm. > >>> > >>> I'm not quite sure how well this fits with sections 2.2.3 restriction > >> that > >>> SHA384 MUST be implemented, and SHA512 SHOULD be implemented. As a > >> recipient > >>> of the zone info I understand that I would need to implement both, but > >> as a > >>> sender am I allowed to only send SHA512, or both, or must I always > send > >> SHA384? > >> > >> As sender (publisher) you are allowed to publish whatever you want. > > [RW] > > > > Okay, taken in conjunction with 2.2.3 that didn't seem clear to me. My > reading is that the sender SHOULD only send one, and [everyone] MUST > support SHA384, effectively implying that is SHA384 that MUST be sent ... > Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to > receivers processing ZONEMD records? ... or some other way to convey the > difference in requirements on algorithm implementation between senders and > receivers. > > > > > Hi Rob, > > To address this, here is what we suggest: > > In sections 2.2.2 and 2.2.3, rather than saying "MUST/SHOULD be > implemented" we'll say "MUST/SHOULD be supported by implementations." > > The paragraph about multiple digests at the start of section 2 will be > moved to this new section 2.5: > > 2.5. Including ZONEMD RRs in a Zone > >The zone operator chooses an appropriate hash algorithm and scheme, >and includes the calculated zone digest in the apex ZONEMD RRset. >The zone operator MAY choose any of the defined hash algorithms and >schemes, including the private use code points. > >The ZONEMD RRSet MAY contain multiple records to support algorithm >agility [RFC7696]. [RFC Editor: change that to BCP 201] When >multiple ZONEMD RRs are present, each MUST specify a unique Scheme >and Hash Algorithm tuple. It is RECOMMENDED that a zone include only >one ZONEMD RR, unless the zone operator is in the process of >transitioning to a new scheme or hash algorithm. > > > DW > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Hi Duane, Please see inline. > -Original Message- > From: iesg On Behalf Of Wessels, Duane > Sent: 09 October 2020 19:36 > To: Rob Wilton (rwilton) > Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski > ; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG > > Subject: Re: Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone- > digest-12: (with COMMENT) > > > > > On Oct 8, 2020, at 4:18 AM, Robert Wilton via Datatracker > wrote: > > > > Robert Wilton has entered the following ballot position for > > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > > > > -- > > COMMENT: > > -- > > > > Thank for you this document. I found it interesting and it looks > useful. > > > > I have a few comments that may improve this document for you to please > consider: > > > > Herein, SHA384 [RFC6234], with value 1, is the only standardized Hash > > Algorithm defined for ZONEMD records that MUST be implemented. When > > SHA384 is used, the size of the Digest field is 48 octets. The > > result of the SHA384 digest algorithm MUST NOT be truncated, and the > > entire 48 octet digest is published in the ZONEMD record. > > > > SHA512 [RFC6234], with Hash Algorithm value 2, is also defined for > > ZONEMD records, and SHOULD be implemented. When SHA512 is used, the > > size of the Digest field is 64 octets. The result of the SHA512 > > digest algorithm MUST NOT be truncated, and the entire 64 octet > > digest is published in the ZONEMD record. > > > > For consistency, perhaps change "with value 1" to "with Hash Algorithm > value 1"? > > Done. > > > > > >2.2.4. The Digest Field > > > > The Digest field MUST NOT be shorter than 12 octets. Digests for > the > > SHA384 and SHA512 hash algorithms specified herein are never > > truncated. Digests for future hash algorithms MAY be truncated, > but > > MUST NOT be truncated to a length that results in less than 96- > bits > > (12 octets) of equivalent strength. > > > > When I read this, I wonder why the limit of 12 bytes was chosen. > Possibly a > > sentence that justifies why this value was chosen might be useful, > noting that > > the two suggested algorithms have significantly longer digests. > > > I know there has been some followup on this with Donald. In our earlier > conversations with him he wrote "96 bits seems to be a common minimum > length for disgests in the IETF although perhaps I have that impression > due to the common case of SHA-1 truncated to 96 bits." > [RW] As per my comment to Ben, I think that you can regard this one as closed. > > > > >2. The ZONEMD Resource Record > > > > It is > > RECOMMENDED that a zone include only one ZONEMD RR, unless the > zone > > publisher is in the process of transitioning to a new Scheme or > Hash > > Algorithm. > > > > I'm not quite sure how well this fits with sections 2.2.3 restriction > that > > SHA384 MUST be implemented, and SHA512 SHOULD be implemented. As a > recipient > > of the zone info I understand that I would need to implement both, but > as a > > sender am I allowed to only send SHA512, or both, or must I always send > SHA384? > > As sender (publisher) you are allowed to publish whatever you want. [RW] Okay, taken in conjunction with 2.2.3 that didn't seem clear to me. My reading is that the sender SHOULD only send one, and [everyone] MUST support SHA384, effectively implying that is SHA384 that MUST be sent ... Perhaps the RFC 2119 language in section 2.2.3 needs to be restricted to receivers processing ZONEMD records? ... or some other way to convey the difference in requirements on algorithm implementation between senders and receivers. > > The purpose of the recommendation above is to hopefully avoid the > situation > where multiple records are published (with both types) on an ongoing > basis. > That is something we observe with DS records quite often. For example, > 750 TLDs today publish both SHA1 and SHA256 digest types as DS records in > the root zone. This new paragraph has been added to the security > considerations: > > 6.2. Use of Multiple ZONEMD Hash Algorithms > >When a zone publishes multiple ZONEMD RRs, the overall security is >only as good as the weakest hash algorithm in use. For this reason, >Section 2
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Hi Ben, Thank you for the explanation and justification. I personally find this sort of explanation really useful. I do wonder whether this sort of material might make a useful informational RFC at some point ... although of course everyone is very busy. But anyway, I think that we can regard my original comment as resolved. Regards, Rob > -Original Message- > From: Benjamin Kaduk > Sent: 10 October 2020 04:25 > To: Rob Wilton (rwilton) > Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski > ; dnsop-cha...@ietf.org; > ; The IESG ; Donald Eastlake > ; Roman Danyliw > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns- > zone-digest-12: (with COMMENT) > > Hi Rob, > > One can do a bit of semi-generic analysis here to help motivate 12 bytes > as > being a tolerable choice (one could make some argument for 32 being the > right length to actually use, but the protocol-mandated floor does not > necessarilly need to be the "full protection" value as there can be > trade-offs in play. > > There's two general classes of attack to consider: when an external > attacker takes an existing ZONEMD and tries to modify the associated zone, > or when the zone provider is the malicious entity that wants to provide > different content to different people but give them the same digest value > so that the cursory examination indicates the two different zones are > identical. (The second one is going to be fairly contrived most of the > time, and may not be in the practical threat model for most people.) In > the former case the cryptographic property in play is second-preimage > resistance which, in the absence of a quantum computer, scales as the > bitlength of the output, so 12 bytes of digest means that for a good hash > function the attacker has to put in a work factor of roughly 2**96, which > is a substantial burden. The cryptographic property in play for the > second > case is regular collision resistance, which scales as the square root of > the preimage problem due to the birthday paradox. > > A work factor of 2**48 is feasible but nontrivial, so 12 bytes poses some > burden for both classes of attack and a substantial burden for the riskier > attack. To me, that seems like a reasonable tradeoff for the bare minimum > allowed by the protocol, though of course opinions can differ. > > -Ben > > On Fri, Oct 09, 2020 at 11:10:14PM -0400, Donald Eastlake wrote: > > Hi Rob, > > > > I'm not aware of any precise analysis supporting the 12 byte minimum > > size but I believe it is reasonable and in line with the lower end of > > the range of hash sizes typically standardized by the IETF these days. > > > > Thanks, > > Donald > > =========== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > d3e...@gmail.com > > > > On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) > wrote: > > > > > > Hi Donald, > > > > > > > -Original Message- > > > > From: Donald Eastlake > > > > Sent: 09 October 2020 00:47 > > > > To: Rob Wilton (rwilton) > > > > Cc: The IESG ; draft-ietf-dnsop-dns-zone- > dig...@ietf.org; > > > > Tim Wicinski ; > ; > > > > dnsop-cha...@ietf.org > > > > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf- > dnsop-dns- > > > > zone-digest-12: (with COMMENT) > > > > > > > > On Thu, Oct 8, 2020 at 7:18 AM Robert Wilton via Datatracker > > > > wrote: > > > > > Robert Wilton has entered the following ballot position for > > > > > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > > > > > > > > ... > > > > > > > > > > -- > > > > > > COMMENT: > > > > > -- > > > > > > > > > > > ... > > > > > > > > > > 2.2.4. The Digest Field > > > > > > > > > >The Digest field MUST NOT be shorter than 12 octets. > Digests for > > > > the > > > > >SHA384 and SHA512 hash algorithms specified herein are > never > > > > >truncated. Digests for future hash algorithms MAY be > truncated, > > > > but > > > > >MUST NOT be truncated to a length that results in less than > 96- > > > > bits > > > > >
Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Hi Donald, > -Original Message- > From: Donald Eastlake > Sent: 09 October 2020 00:47 > To: Rob Wilton (rwilton) > Cc: The IESG ; draft-ietf-dnsop-dns-zone-dig...@ietf.org; > Tim Wicinski ; ; > dnsop-cha...@ietf.org > Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns- > zone-digest-12: (with COMMENT) > > On Thu, Oct 8, 2020 at 7:18 AM Robert Wilton via Datatracker > wrote: > > Robert Wilton has entered the following ballot position for > > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > > > ... > > > > -- > > COMMENT: > > -- > > > > ... > > > > 2.2.4. The Digest Field > > > >The Digest field MUST NOT be shorter than 12 octets. Digests for > the > >SHA384 and SHA512 hash algorithms specified herein are never > >truncated. Digests for future hash algorithms MAY be truncated, > but > >MUST NOT be truncated to a length that results in less than 96- > bits > >(12 octets) of equivalent strength. > > > > When I read this, I wonder why the limit of 12 bytes was chosen. > Possibly a > > sentence that justifies why this value was chosen might be useful, > noting that > > the two suggested algorithms have significantly longer digests. > > To me, the purpose of the limit is to establish a minimum strength > against brute force attacks. Of course, the hash algorithm also has to > be strong but the length of the Digest field puts a sharp limit on the > strength of a ZONEMD. [RW] I absolutely agree on specifying a minimum value. My question is how was the minimum length of "12 bytes" chosen? Is there some analysis performed that indicates that this is the right minimal value, or is this just a "12 bytes sounds like enough"? Regards, Rob > > Note that for the same reason there is a similar provision from 2006 > in RFC 4635, Section 3.1, point 4, which sets a minimum size of 10 > bytes for the hashes that appear in TSIG RRs. > > Thanks, > Donald > === > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e...@gmail.com > > > ... > > > > Regards, > > Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
