Re: [DNSOP] comments on draft-muks-dnsop-dns-message-checksums
Hi Jinmei Thank you for the review. - Original Message - > From: "神明達哉" > To: "dnsop" > Sent: Monday, November 2, 2015 1:31:56 PM > Subject: [DNSOP] comments on draft-muks-dnsop-dns-message-checksums > I've read draft-muks-dnsop-dns-message-checksums-01. I think it's > quite well written. > > I have a couple of comments about the draft: > > 1. I wonder whether this should be merged to draft-ietf-dnsop-cookies, > as both try to solve the same/similar problems with quite similar > approaches (note: I believe I understand the difference, and I'm > not saying dnsop-cookies will make dns-message-checksums > unnecessary). I'm open to merging this with DNS cookies. OTOH, there have been suggestions of adding a dependency on DNS cookies (instead of using the NONCE field) that I'm now not in favour of (which I'll address separately). > 2. Regarding the possibility of downgrade attack, you might want to a > perhaps obvious (and weak) counter measure: cache the availability > of the feature per peer and use it as a hint for further queries. This was also proposed by Shane Kerr. He is planning on contributing a section to the draft towards this. I'll be uploading another revision soon that uses SHA-256, and clarifies some more things that were learned during BIND implementation (e.g., TSIG). Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] comments on draft-jabley-dnsop-refuse-any-01
I've read draft-jabley-dnsop-refuse-any-01. I have a few comments: - Section 3 ANY queries are sometimes used to help mine authoritative-only DNS servers for zone data, since they return all RRSets for a particular owner name. A DNS zone maintainer might prefer not to send full ANY responses to reduce the potential for such information leaks. I'm not opposed to the idea of reducing ANY responses per se, but this rationale doesn't sound very strong to me. There are at most 64K types of records for a particular of name (of the same class), and for a signed zone it's quite easy to get all existing types for a particular name (the number of which would usually be much smaller than 64K in practice). It may be true that sending an ANY query is an easy and cheap way to get all types of records of a particular name today, if you really worry about this type of mining, tweaking ANY response won't help much anyway. - Section 4 1. A DNS responder may choose to search for an owner name that matches the QNAME and, if that name owns multiple RRs, return just one of them. If the choice of the "one" is not deterministic and especially if a zone uses different authoritative server implementations, then it's more likely that they return "inconsistent" responses. This may not be a problem, but we may want to encourage consistent behavior, e.g., by suggesting the choice of smallest (not just 'a small') one in Section 5. - In terms of using ANY query for debugging purposes, and if our main goal is to prevent abuses like amplification attacks rather than mining, I wonder whether we want to allow the original behavior under some conditions, e.g., queries authorized by TSIG or sent over TCP. - I wonder whether we want to use a new type of RR rather than HINFO for synthesized responses. (I've not closely followed discussions on this draft, so perhaps it was already considered and rejected?). -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on draft-wessels-edns-key-tag-00
> On Nov 2, 2015, at 1:23 PM, 神明達哉 wrote: > > I've read draft-wessels-edns-key-tag-00. I think it's generally well > written. I have a few small comments. Thank you for the review. > > - Sections 5.2.1 > > When the recursive server > receives a query with the option set, the recursive server SHOULD set > the edns-key-tag list for any outgoing iterative queries for that > resolution chain to a union of the stub client's Key Tag(s) and the > validating recursive resolver's Key Tag(s). > > What if the recursive server receives the same query from multiple > clients with different key tags and tries to unify the multiple > original queries (some recursive server implementations do this > unification)? Is it expected to include a union of all these key > tags? What if the result of this makes the query too big (even if > it's quite unlikely to happen in practice)? That is an interesting point. I think the implementation should choose its own limit for how many tag values to send in one query. If we need to make a recommendation for the limit I would recommend 10. > > Same questions apply to Section 5.2.2. > > - Regarding security considerations, should we worry about an attack > where the attacker pretends to a massive number of different clients > sending an old key tag, intending to prevent or delay the migration > to a new key? I think this possibility should be documented, although there may be no good solution. The zone operator who collects and analyzes edns-key-tag values should be aware of this potential attack and take reasonable measures to differentiate "real" queries from "attack" queries. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt
Thanks Donald, I'm going to work on the Shepherd writeup and have it out by Thursday. tim On Mon, Nov 2, 2015 at 2:33 PM, Donald Eastlake wrote: > Revised version has been uploaded. > > Thanks, > Donald > = > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e...@gmail.com > > > On Thu, Oct 29, 2015 at 2:17 AM, Tim Wicinski wrote: > > > > > > On 10/28/15 7:03 AM, Donald Eastlake wrote: > >> > >> OK. I could produce an updated draft with fixes for those typos to > >> upload during IETF meeting week but I'm not sure if other changes are > >> desired. > >> > >> Thanks, > >> Donald > > > > > > Please feel free. We've been through WGLC some time back and we've > gotten > > strong consensus, with the editorial caveats that you have addressed. The > > chairs feel it's ready to be moved along, unless something major appears > > from this last update. > > > > tim > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt
Revised version has been uploaded. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Oct 29, 2015 at 2:17 AM, Tim Wicinski wrote: > > > On 10/28/15 7:03 AM, Donald Eastlake wrote: >> >> OK. I could produce an updated draft with fixes for those typos to >> upload during IETF meeting week but I'm not sure if other changes are >> desired. >> >> Thanks, >> Donald > > > Please feel free. We've been through WGLC some time back and we've gotten > strong consensus, with the editorial caveats that you have addressed. The > chairs feel it's ready to be moved along, unless something major appears > from this last update. > > tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-cookies-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Domain Name System (DNS) Cookies Authors : Donald E. Eastlake Mark Andrews Filename: draft-ietf-dnsop-cookies-07.txt Pages : 30 Date: 2015-11-01 Abstract: DNS cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification / forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and anycast and can be incrementally deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-cookies-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
See inline comments: > -Original Message- > From: Edward Lewis [mailto:edward.le...@icann.org] > Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt > > Process wise, you should seek to have this on the experimental track. It > has potential but is far from a sure thing. Edward, Thank you very much for your time. I will need to research more in regard to the experimental track, thank you. Any more advice you could offer here would be great. > > The idea of being able to send formulas for generating responses, > particularly for address records, reverse map and CNAME is a latent need > in the DNS hosting industry. These types are special in that way, so it's > no surprise they are singled out. > > I'll admit that I read and scanned portions to get an idea of what is > discussed. I do like that you have the section 7.1, addressing DNSSEC. > > One "red flag" to me is the idea of hidden wildcards. One of the design > principles of DNSSEC is that it exposes the "thinking" process of the > server to the requestor. That alone isn't a dead end - hidden records and > on-the-fly signing would "work" (but as you note not all name server > implementations have the ability to sign on-the-fly). Good point. Our reasoning behind this was to avoid undue discrimination. Many providers, especially in the context of "anti-spam" make seemingly arbitrary decisions to block or disable huge batches of addresses based on coin-toss accuracy. I've personally seen the simple changing of "dyn" to "static" in a hostname make all the difference and wanted to entirely avoid this set of circumstances where possible. By hiding the fact the records are part of a pattern (i.e. hiding a "BULK" RR request with the same owner) the generated records are no longer susceptible to this form of discrimination. Since one of our primary motivations was in essence to provide $GENERATES which could AXFR there is a zero externally-identifiable change to $GENERATEd records (i.e. no change to operational support). This, of course, is negated where pre-signed DNSSEC records are used and supplemental "NPN" records are required. In this case, hiding the wildcards would prove moot for this purpose. However, the NPN record provides a level of transparency for DNSSEC's "thinking" process while also offering some additional protection against would-be attackers probing DNS for a zone's internal organizational structure a la NSEC. > > Cutting to the chase, there are various elements here that could work > together. But also combinations that wouldn't work so well. Simply put, > this is complicated. For reasons I'll not include here, complicating the > protocol isn't leading in the right direction. Before continuing let me state your opinion is greatly respected and appreciated and my enthusiasm should not be taken as disrespect toward you or your comments in any way. While I wholeheartedly agree this adds a fair amount of complexity to the authoritative side of the equation, disregarding DNSSEC the burden on the recursive side is unaffected. Where DNSSEC is required and on-the-fly is available, the recursive side is just as unaffected. Where DNSSEC is required and on-the-fly is unavailable, we feel this complication is unavoidable. When placed into a similar context as DNSSEC and the complexity of recursively chained cryptographic validation the added complexity supporting these records would add is relatively trivial. > > I do get the desire for this. I also would like to see someway to augment > response synthesis (beyond wildcards). Perhaps a scaled down version > would be more manageable (like removing the hidden records and answering > with the signed formula plus unsigned result - just as for DNAME). Definitely worth a discussion should we get the opportunity. I had no expectation of a first draft making it through the process intact. Thanks again for your prompt response and invaluable insight. Best regards, John > > On 11/2/15, 5:50, "DNSOP on behalf of Woodworth, John R" > wrote: > > >All, > > > >Apologies for any procedural missteps as I am new to the group but am > >trainable. > > > >I am looking to get some traction on a recent I-D my group is working on > >and > >am looking for advice along the way. > > > >We are confident this draft can play a significant role in the future of > >DNS > >especially as it relates to IPv6. While there are many problems we are > >attempting to address with this draft, we believe the biggest among them > >are related to IPv6 and the scarcity of IPv4 address space. > > > >If, by contacting this mailing list, we are heading down the wrong path > >we are > >particularly fond of any advice to move this forward as we see the need > >for it > >becoming more and more important as the adoption of IPv6 increases. > > > > > >The draft announcement is here: > > > >> -Original Message- > >> Subject: New Version Notification for draft-woodworth-bulk-rr-00.txt
[DNSOP] comments on draft-muks-dnsop-dns-message-checksums
I've read draft-muks-dnsop-dns-message-checksums-01. I think it's quite well written. I have a couple of comments about the draft: 1. I wonder whether this should be merged to draft-ietf-dnsop-cookies, as both try to solve the same/similar problems with quite similar approaches (note: I believe I understand the difference, and I'm not saying dnsop-cookies will make dns-message-checksums unnecessary). 2. Regarding the possibility of downgrade attack, you might want to a perhaps obvious (and weak) counter measure: cache the availability of the feature per peer and use it as a hint for further queries. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] comments on draft-wessels-edns-key-tag-00
I've read draft-wessels-edns-key-tag-00. I think it's generally well written. I have a few small comments. - Sections 5.2.1 When the recursive server receives a query with the option set, the recursive server SHOULD set the edns-key-tag list for any outgoing iterative queries for that resolution chain to a union of the stub client's Key Tag(s) and the validating recursive resolver's Key Tag(s). What if the recursive server receives the same query from multiple clients with different key tags and tries to unify the multiple original queries (some recursive server implementations do this unification)? Is it expected to include a union of all these key tags? What if the result of this makes the query too big (even if it's quite unlikely to happen in practice)? Same questions apply to Section 5.2.2. - Regarding security considerations, should we worry about an attack where the attacker pretends to a massive number of different clients sending an old key tag, intending to prevent or delay the migration to a new key? -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
Process wise, you should seek to have this on the experimental track. It has potential but is far from a sure thing. The idea of being able to send formulas for generating responses, particularly for address records, reverse map and CNAME is a latent need in the DNS hosting industry. These types are special in that way, so it's no surprise they are singled out. I'll admit that I read and scanned portions to get an idea of what is discussed. I do like that you have the section 7.1, addressing DNSSEC. One "red flag" to me is the idea of hidden wildcards. One of the design principles of DNSSEC is that it exposes the "thinking" process of the server to the requestor. That alone isn't a dead end - hidden records and on-the-fly signing would "work" (but as you note not all name server implementations have the ability to sign on-the-fly). Cutting to the chase, there are various elements here that could work together. But also combinations that wouldn't work so well. Simply put, this is complicated. For reasons I'll not include here, complicating the protocol isn't leading in the right direction. I do get the desire for this. I also would like to see someway to augment response synthesis (beyond wildcards). Perhaps a scaled down version would be more manageable (like removing the hidden records and answering with the signed formula plus unsigned result - just as for DNAME). On 11/2/15, 5:50, "DNSOP on behalf of Woodworth, John R" wrote: >All, > >Apologies for any procedural missteps as I am new to the group but am >trainable. > >I am looking to get some traction on a recent I-D my group is working on >and >am looking for advice along the way. > >We are confident this draft can play a significant role in the future of >DNS >especially as it relates to IPv6. While there are many problems we are >attempting to address with this draft, we believe the biggest among them >are related to IPv6 and the scarcity of IPv4 address space. > >If, by contacting this mailing list, we are heading down the wrong path >we are >particularly fond of any advice to move this forward as we see the need >for it >becoming more and more important as the adoption of IPv6 increases. > > >The draft announcement is here: > >> -Original Message- >> Subject: New Version Notification for draft-woodworth-bulk-rr-00.txt >> >> >> A new version of I-D, draft-woodworth-bulk-rr-00.txt has been >>successfully >> submitted by John Woodworth and posted to the IETF repository. >> >> Name: draft-woodworth-bulk-rr >> Revision: 00 >> Title:BULK DNS Resource Records >> Document date:2015-06-30 >> Group:Individual Submission >> Pages:28 >> URL: >>https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-00.txt >> Status: >>https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ >> Htmlized: https://tools.ietf.org/html/draft-woodworth-bulk-rr-00 >> >> >> Abstract: >>The BULK DNS resource record type defines a method of pattern based >>creation of DNS resource records to be used in place of NXDOMAIN >>errors which would normally be returned. These records are currently >>restricted to registered DNS resource record types A, , PTR and >>CNAME. The key benefit of the BULK resource record type is the >>simplification of maintaining "generic" record assignments which >>would otherwise be too many to manage or require scripts or >>proprietary methods as bind's $GENERATE. >> > > >Thanks and best regards, >John >This communication is the property of CenturyLink and may contain >confidential or privileged information. Unauthorized use of this >communication is strictly prohibited and may be unlawful. If you have >received this communication in error, please immediately notify the >sender by reply e-mail and destroy all copies of the communication and >any attachments. >___ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] meeting prep: scribes
Hi, DNSOP meets in the morning slot on Thursday. Final agenda coming soon— thanks for your patience. As usual, we’re looking for a minute taker and a jabber scribe— if you’re willing to help out, please let the chairs know— off-list is fine. thanks, Suzanne & Tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
All, Apologies for any procedural missteps as I am new to the group but am trainable. I am looking to get some traction on a recent I-D my group is working on and am looking for advice along the way. We are confident this draft can play a significant role in the future of DNS especially as it relates to IPv6. While there are many problems we are attempting to address with this draft, we believe the biggest among them are related to IPv6 and the scarcity of IPv4 address space. If, by contacting this mailing list, we are heading down the wrong path we are particularly fond of any advice to move this forward as we see the need for it becoming more and more important as the adoption of IPv6 increases. The draft announcement is here: > -Original Message- > Subject: New Version Notification for draft-woodworth-bulk-rr-00.txt > > > A new version of I-D, draft-woodworth-bulk-rr-00.txt has been successfully > submitted by John Woodworth and posted to the IETF repository. > > Name: draft-woodworth-bulk-rr > Revision: 00 > Title:BULK DNS Resource Records > Document date:2015-06-30 > Group:Individual Submission > Pages:28 > URL: > https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-00.txt > Status: https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > Htmlized: https://tools.ietf.org/html/draft-woodworth-bulk-rr-00 > > > Abstract: >The BULK DNS resource record type defines a method of pattern based >creation of DNS resource records to be used in place of NXDOMAIN >errors which would normally be returned. These records are currently >restricted to registered DNS resource record types A, , PTR and >CNAME. The key benefit of the BULK resource record type is the >simplification of maintaining "generic" record assignments which >would otherwise be too many to manage or require scripts or >proprietary methods as bind's $GENERATE. > Thanks and best regards, John This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
Hi The authors have updated their document to address all outstanding issues, and we feel the document is ready for Working Group Last Call. This starts a Working Group Last Call for draft-ietf-dnsop-edns-chain-query Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons. Currently the document is marked “Standards Track”, but due to lack of implementations at this time (though some are being worked), I am suggesting we apply the “Experimental” label to this. The working group is welcome to chime inhere. Because we are at IETF this week, we will set aside time at the microphones for any issues that members wish to raise. This starts a two week Working Group Last Call process, and ends on Sunday 15 November 2015. thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 6761bis Design Team Lead
On Sun, Nov 1, 2015 at 2:40 AM, Tim Wicinski wrote: > All, > > In the interests of supporting the 6761 design team moving forward, we’re > naming a lead for it— someone whose job is not only to participate in the > work as he’s able, but to enable progress for the entire team. > > Ralph Droms has significant history with the 6761 issues (he was the AD who > shepherded the document and is eager to be helpful in improving the > situation we find ourselves in) and extensive experience making sure > progress occurs in IETF design teams and WGs. We’ve asked him to lead the > design team and he has accepted. > > Ralph, thank you for taking on this particular bit of cat-herding. > > The chairs will of course continue to monitor activities and progress. Great. The chairs also asked for volunteers for the design team on October 8th; a number of people volunteered - it would be nice to know what happened with that. Sorry for sounding frustrated, but, well, I'm a bit frustrated... W > > thanks, > > Suzanne/Tim > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] 6761bis Design Team Lead
All, In the interests of supporting the 6761 design team moving forward, we’re naming a lead for it— someone whose job is not only to participate in the work as he’s able, but to enable progress for the entire team. Ralph Droms has significant history with the 6761 issues (he was the AD who shepherded the document and is eager to be helpful in improving the situation we find ourselves in) and extensive experience making sure progress occurs in IETF design teams and WGs. We’ve asked him to lead the design team and he has accepted. Ralph, thank you for taking on this particular bit of cat-herding. The chairs will of course continue to monitor activities and progress. thanks, Suzanne/Tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
