Re: [DNSOP] Preliminary Agenda for
On Thu, 9 Mar 2017 21:29:25 + Tim Wicinski wrote: > * draft-kristoff-dnsop-dns-tcp-requirements > DNS Transport over TCP - Operational Requirements Oh thanks Tim. I wasn't sure if this was going to make it into the WG's plans. I had started a revised version of the draft, which I intend to have updated and uploaded by the 13th for review. The last -01 version just expired a few days ago, but should be easily found if anyone wants to take a look at it. Here are the changes that I've made or may make for the next revision based in part on some comments already given: * Some grammatical, spelling fixes. * At least a mention of IETF RFC 7858 (DNS over TLS) * Revamped Requirements section. * Possibly some operational guidance like that found in section 10 of IETF RFC 7766 (DNS over TCP implementation requirements) * Possibly some history of TCP versus UDP implementation differences. * Possibly a summary of current DNS standards related to TCP. More comments welcome of course. John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated NSEC5 protocol spec and paper
> On 9 Mar 2017, at 21:12, Phillip Hallam-Baker wrote: > > > > On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends wrote: > > > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker wrote: > > > > I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT > > issue entirely. > > What is NSEC0? > > > That which "simply nulls out the whole NSEC/NXT issue entirely.” What is “the whole NSEC/NXT issue” ? Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Preliminary Agenda for
All I've submitted an initial agenda, though I realize already I missed 1 or 2. I will update once I reach my next destination. Also, the question for MeetEcho is whether anyone wishes to present remotely at IETF98. If so, please let us know so we can make preparations. The meeting is Monday afternoon at 1pm, so I am hoping all slides will be submitted to the chairs by the weekend. https://www.ietf.org/proceedings/98/agenda/agenda-98-dnsop-00 thanks tim -- ## DNS Operations (DNSOP) Working Group # IETF 98, Chicago ### Date: Monday 27 March 2017 ### Time: 13:00-15:00 CST (19:00-21:00 UTC) ### Room: Zurich D ### Chairs: Tim Wicinski ### Chairs: Suzanne Woolf ## Secretary: Paul Hoffman [DocList](https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html) [DataTracker](https://datatracker.ietf.org/wg/dnsop/documents/) --- # Agenda ### Agenda Bashing, Blue Sheets, etc, 10 min ### Updates of Old Work, Chairs * Hoffman, [dns-terminology-bis](https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), 10 min ## Current Working Group Business * draft-woodworth-bulk-rr BULK DNS Resource Records draft-ietf-dnsop-dns-capture-format C-DNS: A DNS Packet Capture Format ## New Working Group Business * draft-vcelak-nsec5 NSEC5, DNSSEC Authenticated Denial of Existence * draft-kristoff-dnsop-dns-tcp-requirements DNS Transport over TCP - Operational Requirements * draft-bellis-dnsop-xpf EDNS X-Proxied-For * draft-sury-dnssec-nsec3-blake2 Use of BLAKE2 Algoritms in Hashed Authentication Denial of Existence (NSEC3) Records for DNSSEC * draft-tale-dnsop-edns0-clientid Client ID in Forwarded DNS Queries ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated NSEC5 protocol spec and paper
I believe one of the authors of the paper works for a DNS Vendor, so it would be interesting gauge deployment. tim On 3/9/17 12:31 PM, Paul Hoffman wrote: On 7 Mar 2017, at 7:29, Shumon Huque wrote: We've requested an agenda slot at the DNSOP working group meeting at IETF98 to talk about the NSEC5 protocol. Our chairs have requested that we send out a note to the group ahead of time, so here it is. This protocol has not to our knowledge been presented at dnsop before, but has been discussed previously at other IETF venues, such as SAAG. The protocol described in draft-vcelak-nsec5 has improved since it was first presented, but it is still unclear why we should adopt it as part of DNSSEC. The benefits listed in the draft are real, but they come at a very steep cost for zone administrators who might use NSEC5. Is there a community of zone admins who want this so much that they won't start signing until it exists? Short of that, is there a community of zone admins who are using NSEC/NSEC3 white lies who find this to be a significant improvement? If not, adopting this seems like a bad idea. No one can operationally sign with NSEC5 until nearly all validators have it installed. In the meantime, a zone admin who cares about zone enumeration and wants to sign will use white lies, and those who don't care about zone enumeration won't pay any attention to this. Even though this document has some really nice design decisions in it, should it be adopted in DNSSEC unless it is likely to be deployed? --Paul Hoffman ___ 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] Updated NSEC5 protocol spec and paper
On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends wrote: > > > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker > wrote: > > > > I suggest we first deploy NSEC0 which simply nulls out the whole > NSEC/NXT issue entirely. > > What is NSEC0? > > That which "simply nulls out the whole NSEC/NXT issue entirely." To be specified but we could do that if we wanted to. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated NSEC5 protocol spec and paper
On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends wrote: > > > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker > wrote: > > > > I suggest we first deploy NSEC0 which simply nulls out the whole > NSEC/NXT issue entirely. > > What is NSEC0? > > That which "simply nulls out the whole NSEC/NXT issue entirely." To be specified but we could do that if we wanted to. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated NSEC5 protocol spec and paper
> On 9 Mar 2017, at 20:58, Phillip Hallam-Baker wrote: > > I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT > issue entirely. What is NSEC0? Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated NSEC5 protocol spec and paper
The perfect is the enemy of the good. I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT issue entirely. At this point anyone who is deploying DNSSEC is helping the cause. Do not set membership requirements that exclude them. Node insertion is a security concern for some DNSSEC applications but not for all. Implementing NSEC0 would not be a burden on validators. If nobody uses it then there is no harm to it. If people only use it for a short time during deployment then it is useful. If people use it and won't stop then that is proof of a demand for NSEC5. I completely reject your notion of where validation occurs and what the value is BTW but that is a different issue. Bottom line is that I do not depend on validators being deployed to the end points as I do not expect that to happen soon and quite possibly not ever. On Thu, Mar 9, 2017 at 12:31 PM, Paul Hoffman wrote: > On 7 Mar 2017, at 7:29, Shumon Huque wrote: > > We've requested an agenda slot at the DNSOP working group meeting at >> IETF98 to talk about the NSEC5 protocol. Our chairs have requested that >> we send out a note to the group ahead of time, so here it is. >> >> This protocol has not to our knowledge been presented at dnsop before, >> but has been discussed previously at other IETF venues, such as SAAG. >> > > The protocol described in draft-vcelak-nsec5 has improved since it was > first presented, but it is still unclear why we should adopt it as part of > DNSSEC. The benefits listed in the draft are real, but they come at a very > steep cost for zone administrators who might use NSEC5. > > Is there a community of zone admins who want this so much that they won't > start signing until it exists? > > Short of that, is there a community of zone admins who are using > NSEC/NSEC3 white lies who find this to be a significant improvement? > > If not, adopting this seems like a bad idea. No one can operationally sign > with NSEC5 until nearly all validators have it installed. In the meantime, > a zone admin who cares about zone enumeration and wants to sign will use > white lies, and those who don't care about zone enumeration won't pay any > attention to this. > > Even though this document has some really nice design decisions in it, > should it be adopted in DNSSEC unless it is likely to be deployed? > > --Paul Hoffman > > > ___ > 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] Updated NSEC5 protocol spec and paper
> On Mar 9, 2017, at 18:31, Paul Hoffman wrote: > > The protocol described in draft-vcelak-nsec5 has improved since it was first > presented, but it is still unclear why we should adopt it as part of DNSSEC. > The benefits listed in the draft are real, but they come at a very steep cost > for zone administrators who might use NSEC5. > > Is there a community of zone admins who want this so much that they won't > start signing until it exists? > If not, adopting this seems like a bad idea. I agree with this summary. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
> On Mar 9, 2017, at 18:54, tjw ietf wrote: > We’re going to go ahead and adopt it for DNSOP, with the intention of > resolving the concerns people expressed by keeping the status as > informational (not standards track) and making sure the cautions and > limitations the WG discussed on the use of RPZ are clear in the document. I don't understand how this works. The authors clearly stated the document will describe only what is currently implemented and they were not willing to make changes. How can this ever turn into a real WG document? Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dns-rpz-00.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 of the IETF. Title : DNS Response Policy Zones (RPZ) Authors : Paul Vixie Vernon Schryver Filename: draft-ietf-dnsop-dns-rpz-00.txt Pages : 30 Date: 2017-03-09 Abstract: This document describes a method for expressing DNS response policy inside a specially constructed DNS zone, and for recursive name servers to use such policy to return modified results to DNS clients. The modified DNS results can stop access to selected HTTP servers, redirect users to "walled gardens", block objectionable email, and otherwise defend against attack. These "DNS Firewalls" are widely used in fighting Internet crime and abuse. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00 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] DNSOP Call for Adoption draft-vixie-dns-rpz
All The Call for Adoption on draft-vixie-dns-rpz ended some time ago, and the results were a solid in favor of adoption. However, the legitmacy of the argument in opposition to adopting seems fairly significant about certain parts of the draft. In discussing this with our AD, the opinion is that if this same opposition manifests in the IETF last call there would have reservations about advancing it. So if we consider this rough consensus for the purposes of adoption it means we believe we will be better off with an improved, working- group-owned document then this one. We’re going to go ahead and adopt it for DNSOP, with the intention of resolving the concerns people expressed by keeping the status as informational (not standards track) and making sure the cautions and limitations the WG discussed on the use of RPZ are clear in the document. thanks tim suzanne On Tue, Dec 20, 2016 at 10:16 AM, tjw ietf wrote: > Why not just wade into this discussion... > > The draft is being present as "Informational", and the point here is to > document current working behavior in the DNS (for the past several years). > It is obvious that some feel this draft is a large mistake, but like > edns-client-subnet, more operators are deploying this than one is aware of. > > This starts a Call for Adoption for draft-vixie-dns-rpz > > The draft is available here: > https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > With the holiday period upon us, we'll make this a three week call for > adoption. This call for adoption ends on 10 January 2017 > > Thanks, > tim wicinski > DNSOP co-chair > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated NSEC5 protocol spec and paper
On 7 Mar 2017, at 7:29, Shumon Huque wrote: We've requested an agenda slot at the DNSOP working group meeting at IETF98 to talk about the NSEC5 protocol. Our chairs have requested that we send out a note to the group ahead of time, so here it is. This protocol has not to our knowledge been presented at dnsop before, but has been discussed previously at other IETF venues, such as SAAG. The protocol described in draft-vcelak-nsec5 has improved since it was first presented, but it is still unclear why we should adopt it as part of DNSSEC. The benefits listed in the draft are real, but they come at a very steep cost for zone administrators who might use NSEC5. Is there a community of zone admins who want this so much that they won't start signing until it exists? Short of that, is there a community of zone admins who are using NSEC/NSEC3 white lies who find this to be a significant improvement? If not, adopting this seems like a bad idea. No one can operationally sign with NSEC5 until nearly all validators have it installed. In the meantime, a zone admin who cares about zone enumeration and wants to sign will use white lies, and those who don't care about zone enumeration won't pay any attention to this. Even though this document has some really nice design decisions in it, should it be adopted in DNSSEC unless it is likely to be deployed? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
