Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
Having said that, just what level of significance would it take for us to bend in this respect? What type of feature, etc.? For DNSSEC the issue was the fundamental integrity of the DNS. I think it's fair to say that this isn't that. ...BULK absolutely requires online DNSSEC signing, Unfortunately, I respectfully reject this as a statement of fact. There's even a provision (NPN) ... ... which only works if you upgrade every validating resolver. If you get to do that, you might as well just send the signed BULK record, the NSEC and RRSIG that show there's nothing at the name, and let the resolver figure it out. Given how slowly people update their client DNS libraries, NPN would be a recipe for decades of DNS flakiness, as some resolvers accept the generated records and some don't. As I said a few messages ago, this really needs to wait until we figure out how to signal DNS versioning, and if we don't want to wait for every resolver in the world to be updated, how to distribute signing keys along with AXFR/IXFR to allow online signing to work portably. I'm not opposed to BULK because I don't think it's useful -- there are plenty of RRs that are useless but harmless. But I really don't want to break the DNS, particularly for something that is at most arguably useful. R's, John PS: I hope it's self evident why "it doesn't matter because hardly anyone uses DNSSEC" is not a persuasive argument. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Andrew Sullivan > > On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote: > > This basically means that BULK is a master-only feature, which implies > > that there's no need for BULK to work across zone transfers, which > > implies the need to standardize it for interop is almost nonexistent. > > I don't think that follows. > > The DNS market is, like the mail market did some while ago, > undergoing a period of consolidation in which a fairly small number > of people have a very large number of dependent customers. > Unfortuantely, whereas mail is asynchronous, DNS is effectively > synchronous: if the provder has a bad day and you can't get an > answer the site is down. > This means that customers want to have multiple different vendors > as their master, and they want the secondaries of those sources to > offer as much as possible the same features, even when various DNS > Tricks are in use; and they want the downstreams to be using > standard protocols. The more we can make interoperate to support > that, the better off those users are. > Hi Andrew, Thanks for the feedback and support! Thanks, John > > Best regards, > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com -- THESE ARE THE DROIDS TO WHOM I REFER: 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
Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
> From: Tony Finch [mailto:d...@dotat.at] > Hi Tony, Thanks for the feedback. > > John R Levine wrote: > > > > BULK absolutely requires online DNSSEC signing, > > This basically means that BULK is a master-only feature, which > implies that there's no need for BULK to work across zone > transfers, which implies the need to standardize it for > interop is almost nonexistent. > Although BULK does actually offer an offline DNSSEC signing solution, no such solution is required for unsigned zones which today is where all the implementations I am aware of live anyway. Thanks, John > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I > xn--zr8h punycode Lundy, Fastnet, Irish Sea: South or southwest > becoming cyclonic, 5 to 7, perhaps gale 8 later. Moderate or > rough, becoming rough or very rough later in Fastnet and west > Lundy. Rain or thundery showers. Good, occasionally poor. -- THESE ARE THE DROIDS TO WHOM I REFER: 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
Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
> -Original Message- > From: John R Levine [mailto:jo...@taugh.com] > Hi John, Thanks again for your feedback. > > On Thu, 20 Jul 2017, Woodworth, John R wrote: > > Camp#2) Don't break DNS, even for a second > > Well, yeah, except that there's no such thing as breaking the > DNS for a second. If we look at the history of DNSSEC, we'd > break the DNS for somewhere between a decade and forever. > We have tried very hard for three decades to avoid breaking > backward compatibility, and it's hard to believe that this is > the reason to do it. > This is a very noble endeavor indeed, I both applaud and respect it. Having said that, just what level of significance would it take for us to bend in this respect? What type of feature, etc.? > > ...BULK absolutely requires online DNSSEC signing, > Unfortunately, I respectfully reject this as a statement of fact. There's even a provision (NPN) in the draft which offers a reasonable method designed specifically for offline signatures. While the NPN documentation is imperfect, we've still seen a lot of interest it, and with the help of the WG, we feel it could prove very useful. Thanks, John > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, > Trumansburg NY Please consider the environment before reading > this e-mail. https://jl.ly -- THESE ARE THE DROIDS TO WHOM I REFER: 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
Re: [DNSOP] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
On Fri, 21 Jul 2017, Matthew Pounsett wrote: Dear $VENDOR. I'm a customer who is considering deploying the BULK RR type into my zone, and I would like to know whether your systems support it. Thank you, $CUSTOMER. Dear $CUSTOMER, Thank you for your question. Here at $VENDOR we take pride in our six-sigma state of the art customer focused service. We use industry standard Apache and BIND software on most of our systems, and nginx and NSD on the rest. Thank you for the opportunity to be of service, Sincerely, "Bob", $VENDOR associate customer specialist I think you overestimate how much a typical non-specialist DNS provider knows about their software. If you don't believe me, write to a few and ask whether they need DS or DNSKEY to make a secure delegation. That said.. there is still an issue with key distribution for online signing which is required to make this work. I see the utility in BULK, but I'm persuaded that there needs to be more work before it's deployable in an environment where *XFR is required. No kidding. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
Hello John, On 20 Jul 2017, at 3:17, Woodworth, John R wrote: Although in practice the name would likely be shorter and potentially include other customer attributes, say acmewabbit-21f-5bff-fec3-ab9d.example.com 1. This shows the owner is example.com, customer acmewabbit 2. Reverse lookups are helpful for tools (e.g. traceroute) and logs. 1 and 2 could be covered with a wildcard PTR, as I think Tony Finch pointed out. Forget for a moment about IPv6. This draft makes $GENERATE more memory efficient, scales bigger, stays intact through AXFR's and yes -it makes some nameservers (authoritative) work a bit more as a trade-off. One could make $GENERATE more efficient without actually implementing the BULK RR, by taking your pattern matching logic and implementing it inside the name server. Of course, this makes generating the NSEC/NSEC3 chain much harder than it is with today’s $GENERATE implementations that actually generate all the names. A very interesting puzzle would be implementing BULK support, based on the pattern matching in the draft, -without- doing NSEC(3) white/black lies - i.e. generating the widest possible NSEC instead of the narrowest one. For NSEC3 I suspect this is not feasible. 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] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
Tim, On 20 Jul 2017, at 14:09, tjw ietf wrote: Another Data Point: One of the Apps Area ADs stopped by to tell the chairs that 1) they like the general idea; 2) their employer has a need for this *outside of the PTR space*; and 3) would be willing to shepherd the work through. Now, they also the first to admit that the Application people do the most abuse to DNS standards (hence the need for the attrleaf document). In fact, my employer, who is quite abusive in how they deploy CNAMEs could very easily work up a very legitimate use case for using BULK for deploying some of our larger zones. Add that to the fact that my employer insists on deploying DNS between multiple vendors - whether it is DNS software or managed DNS services. It would be very helpful if the mentioned AD, or your employer, could elaborate on these use cases. As it stands we (PowerDNS) do not see the point of BULK (even though we are capable of online signing and thus have it easier than some of the other name servers), but we could certainly be convinced otherwise. 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] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)
Hello George, On 21 Jul 2017, at 14:58, George Michaelson wrote: I (for one) hang onto the .req file. Maybe thats naughty, but I do, so in my case Warren routine is that the keypair is being reused, because.. well.. because I like to. Software I consume I suspect (like you) doesn't, and re-mints shiny new keys now with added keynomium, but when I do it by hand? yes I reuse the .req file. As a data point, several Let’s Encrypt clients will reuse keys. Those that do not by default can often be configured to do so. The benefits of reusing the key should be obvious to anyone that also uses TLSA. If you think about it, a TLSA record is also a certificate, but your signer auto-renews it for you. 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] NSEC/NSEC3 for unsigned zones and aggressive use
On 20 Jul 2017, at 17:00, Stephane Bortzmeyer wrote: draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can now synthetizes answers) so it seems to me the same reasons should apply? That it is more aggressive, -and- that it relies on a feature of DNSSEC, suggests that we SHOULD be stricter here, and the only interpretation of ‘stricter’ I can imagine is requiring DNSSEC. However, I have advocated (offline) in the past for allowing unsigned NSEC to be used to deter PRSD attacks, allowing the resolver to reduce queries to the targeted auth by >90% - a win for both sides. It is a tricky balance. If somebody is under attack, that surely is the worst time for them to upload a DS, while enabling DNSSEC on their end (which would come with RRSIGs that validators then ignore) as a mitigation strategy that actually works, would be wonderful to have. 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] DNS versioning, was The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"
On 20 July 2017 at 17:53, John R Levine wrote: > That's why I don't share the fears about BULK: you cannot easily >> deploy a new feature that will require a change in the resolvers, >> because you don't know all the resolvers, and cannot change them even >> if you know they are too old. But your secondaries are only a small >> set of carefully chosen servers, and you have your say. >> > > I hear otherwise from people who run big DNS farms. It's common to use > multiple secondary providers, and it's hard to tell who's running what > server software. I also note that it took about a decade before people > felt comfortable using DNAMEs. > Dear $VENDOR. I'm a customer who is considering deploying the BULK RR type into my zone, and I would like to know whether your systems support it. Thank you, $CUSTOMER. That said.. there is still an issue with key distribution for online signing which is required to make this work. I see the utility in BULK, but I'm persuaded that there needs to be more work before it's deployable in an environment where *XFR is required. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)
I've also heard the "changing the keys is good hygiene" argument -- if someone has wandered off with your private keys (like an old administrator) you have limited how long they can reuse them but, a: there is room for argument and b: we have gotten way down into the weeds here... W On Fri, Jul 21, 2017 at 2:58 PM, George Michaelson wrote: > A fine bit of epistemology lies in the question: is it the same > certificate, if you re-issue it with the same keys? No, because it has > a different serial. but the crypto doesn't care, its the validation > which cares which is a product of the crypto. so validation cares but > cryptographic functions themselves, not such. > > The nice thing about bare key cryptography, is that fish don't need > bicycles. Dates are dates and validity intervals are a thing, but you > can re-bake as many times as you like if there is nothing embedded in > the structure like a serial. Oh wait.. we sign the SOA don't we... > > I (for one) hang onto the .req file. Maybe thats naughty, but I do, so > in my case Warren routine is that the keypair is being reused, > because.. well.. because I like to. Software I consume I suspect (like > you) doesn't, and re-mints shiny new keys now with added keynomium, > but when I do it by hand? yes I reuse the .req file. > > But I am probably being led into bad places as a result. I am sure > wiser heads will say. > > On Fri, Jul 21, 2017 at 1:46 PM, Warren Kumari wrote: >> On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: >>> Andrew Sullivan wrote: For instance, people also express astonishment that DNSKEYs don't expire. Everyone always has to be reminded that signatures expire, and if you want to expire keys you take them out of the zone. >>> >>> I agree with your message. >>> >>> It might be useful to explain this DNSKEY oddity by comparison with x.509 >>> certificates. In particular, it's the cert that expires, not the key, and >>> when you renew a cert you can re-use the same key. >> >> >> Yeah, you *can* reuse the same key, but (I suspect) most don't -- from >> what I've seen, then general process is: >> 1: Erk! My cert is about to / has just expired!!! >> 2: Search for and follow some online recipe related to "make ssl certificate" >> 3: >> 4: Go back to sleep. >> >> I think that (but would be happy to be proven wrong) that most >> certificate renewals[0] involve a change of keys too. >> >> W >> [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. >> >>> >>> Tony. >>> -- >>> f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode >>> Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 >>> veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or >>> rough. Rain or showers. Good, occasionally poor. >>> >>> ___ >>> 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 -- 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
Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)
A fine bit of epistemology lies in the question: is it the same certificate, if you re-issue it with the same keys? No, because it has a different serial. but the crypto doesn't care, its the validation which cares which is a product of the crypto. so validation cares but cryptographic functions themselves, not such. The nice thing about bare key cryptography, is that fish don't need bicycles. Dates are dates and validity intervals are a thing, but you can re-bake as many times as you like if there is nothing embedded in the structure like a serial. Oh wait.. we sign the SOA don't we... I (for one) hang onto the .req file. Maybe thats naughty, but I do, so in my case Warren routine is that the keypair is being reused, because.. well.. because I like to. Software I consume I suspect (like you) doesn't, and re-mints shiny new keys now with added keynomium, but when I do it by hand? yes I reuse the .req file. But I am probably being led into bad places as a result. I am sure wiser heads will say. On Fri, Jul 21, 2017 at 1:46 PM, Warren Kumari wrote: > On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: >> Andrew Sullivan wrote: >>> >>> For instance, people also express astonishment that DNSKEYs don't >>> expire. Everyone always has to be reminded that signatures expire, and >>> if you want to expire keys you take them out of the zone. >> >> I agree with your message. >> >> It might be useful to explain this DNSKEY oddity by comparison with x.509 >> certificates. In particular, it's the cert that expires, not the key, and >> when you renew a cert you can re-use the same key. > > > Yeah, you *can* reuse the same key, but (I suspect) most don't -- from > what I've seen, then general process is: > 1: Erk! My cert is about to / has just expired!!! > 2: Search for and follow some online recipe related to "make ssl certificate" > 3: > 4: Go back to sleep. > > I think that (but would be happy to be proven wrong) that most > certificate renewals[0] involve a change of keys too. > > W > [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. > >> >> Tony. >> -- >> f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode >> Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 >> veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or >> rough. Rain or showers. Good, occasionally poor. >> >> ___ >> 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)
On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: > Andrew Sullivan wrote: >> >> For instance, people also express astonishment that DNSKEYs don't >> expire. Everyone always has to be reminded that signatures expire, and >> if you want to expire keys you take them out of the zone. > > I agree with your message. > > It might be useful to explain this DNSKEY oddity by comparison with x.509 > certificates. In particular, it's the cert that expires, not the key, and > when you renew a cert you can re-use the same key. Yeah, you *can* reuse the same key, but (I suspect) most don't -- from what I've seen, then general process is: 1: Erk! My cert is about to / has just expired!!! 2: Search for and follow some online recipe related to "make ssl certificate" 3: 4: Go back to sleep. I think that (but would be happy to be proven wrong) that most certificate renewals[0] involve a change of keys too. W [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode > Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 > veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or > rough. Rain or showers. Good, occasionally poor. > > ___ > 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
Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)
Andrew Sullivan wrote: > > For instance, people also express astonishment that DNSKEYs don't > expire. Everyone always has to be reminded that signatures expire, and > if you want to expire keys you take them out of the zone. I agree with your message. It might be useful to explain this DNSKEY oddity by comparison with x.509 certificates. In particular, it's the cert that expires, not the key, and when you renew a cert you can re-use the same key. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or rough. Rain or showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
On Fri, Jul 21, 2017 at 10:24:35AM +0200, Petr Špaček wrote: > On 19.7.2017 10:50, Francis Dupont wrote: > > In your previous mail you wrote: > > > >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in > >> unsigned zones. In this case the unsigned NSEC would also not be part of > >> the zone (it would have to be synthesized and maintained outside the > >> zone). > > > > => but it is created by an authoritative server, isn't it? > > And as it is synthesized I can't see a good reason to use NSEC3 instead. > > > >> Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix > >> entire zones, when it was discussed, Mark Andrews suggested that > >> requiring DNS COOKIE to further reduce the chance of cache poisoning > >> (more than source port randomization and random message ID) could be a > >> reasonable idea to think about. > > > > => it adds a nonce so another (short) bunch of unpredictable bits. > > As NSEC is not signed it is more than vulnerable to on-the-path attacks. > > I am afraid it is first a massive zone destruction weapon and after > > perhaps an optimization... > > Oh yes, very good point Francis. Let me repeat that I'm against this > proposal. The zone is unsigned. An on-path attacker can do pretty much whatever he pleases anyway including poisoning cache and denying service. The addition of the cookie was to prevent the risk of an off-path attack becoming a massive zone destruction weapon. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
George, > On Jul 20, 2017, at 1:00 PM, George Michaelson wrote: > > I probably will not carry the WG with me on this, but I find myself > thinking the PII aspect of client-ID makes it a wider-internet > question and we might have views as a WG, and promote questions as a > WG, but I think the "final call" on this is something which needs more > than WG approval. A couple of points of precision on this: first, I’m not sure “PII” is rigorously defined in our context, so we might need to be more specific on that (although I agree with the intuitive sense you seem to have about it). Second, technically the WG doesn’t approve publication of a document anyway; a decision by the WG to advance a particular document along the process is neither necessary nor sufficient to get it published; there are several additional steps to publication approval. With those things said, however: > > Its a big question. I'd actually welcome adoption on many levels, but > that isn't to pre-empt that it goes to WGLC. I think we need to > formalize the issues and take them out of the WG for review and > discussion. > > documenting current practice is ok btw, but .. PII. > Agreed there are some aspects here that need cross-area review, and making sure that happens is part of the chairs’ followup from discussion of the draft to date. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
On 20.7.2017 17:00, Stephane Bortzmeyer wrote: > On Tue, Jul 18, 2017 at 06:20:56PM +0530, > Mukund Sivaraman wrote > a message of 27 lines which said: > >> It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned >> zones. > > That's quite funny. During the development of RFC 8020 > (draft-ietf-dnsop-nxdomain-cut), which addresses the same concern as > draft-ietf-dnsop-nsec-aggressiveuse, many people said that the feature > was dangerous, and we should mandate the use of DNSSEC. In the end, it > is not mandatory (see sections 2, 3rd para, and section 7 of RFC > 8020). It is worth noting that implementation in Unbound enables this only for DNSSEC-signed zones to avoid problems with broken CDNs. In other words, DNSSEC is used as indicator "we can do DNS properly". That sounds reasonable to me. Petr Špaček @ CZ.NIC > draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can > now synthetizes answers) so it seems to me the same reasons should > apply? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
On 19.7.2017 10:50, Francis Dupont wrote: > In your previous mail you wrote: > >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in >> unsigned zones. In this case the unsigned NSEC would also not be part of >> the zone (it would have to be synthesized and maintained outside the >> zone). > > => but it is created by an authoritative server, isn't it? > And as it is synthesized I can't see a good reason to use NSEC3 instead. > >> Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix >> entire zones, when it was discussed, Mark Andrews suggested that >> requiring DNS COOKIE to further reduce the chance of cache poisoning >> (more than source port randomization and random message ID) could be a >> reasonable idea to think about. > > => it adds a nonce so another (short) bunch of unpredictable bits. > As NSEC is not signed it is more than vulnerable to on-the-path attacks. > I am afraid it is first a massive zone destruction weapon and after > perhaps an optimization... Oh yes, very good point Francis. Let me repeat that I'm against this proposal. Petr Špaček @ CZ.NIC > >> > It seems easier to remember that DNSSEC offers proofs for denial of >> > existence. > > => still applies... > > Regards > > francis.dup...@fdupont.fr > > PS: really if this is deployed I can see more "interesting" ways for misuses > than real benefits. Of course it can be a mean to make zone managers ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
I am hearing from a number of people that this is "a new protocol" and hence requires careful thought and perhaps a new working group, along with the associated delay. I do not _entirely_ disagree with this position, although it would be really inconvenient from my perspective. However, I would like to point out that the objection "it is a new protocol" is not a technical objection. Also, the same objection can actually much more justly be raised against several other proposals that were brought before the working group. For example, the multiple RRtypes proposal, the multiple responses proposal, and the extended error codes proposal. All of these define new protocol, in ways that are in, like session signaling, backward-compatible with the existing protocol. The other proposals are actually much more significant changes than session signaling is, in terms of what they actually do, as opposed to what their wire format is. And as for a new DNS wire format, which I also think would be a good idea, this is pretty clearly *not *what session signaling is. How would you do a DNS query with session signaling? In what way would it be an improvement over the existing query format? It's possible that a new wire format can be built on top of session signaling, but session signaling doesn't build a new wire format, and if we choose to do session signaling, that doesn't preclude doing a different wire format for queries later. Session signaling is just a control plane for DNS. It's useful. I would like to see it done sooner rather than later. If we are not going to do it sooner rather than later, I would like the reason to be something more than vague unease about walking backwards into a new wire format. On Fri, Jul 21, 2017 at 10:02 AM, Petr Špaček wrote: > On 20.7.2017 19:09, Andrew Sullivan wrote: > > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: > >>> But it's certainly another step along the way to DNSbis by accident. > >> > >> Would it be useful to make it not "by accident"? > > > > Yes. That was basically the point I was trying to make at the > > beginning of today's session, about overall analysis. > > > > > b) make this draft DNS-SD only, so it can fast forward... > >> > > > > I'm not keen on this. > > > > > >> c) use the changed paradigm to work on DNSbis without the accident part? > > Yes please! > > My main opposition comes from fact that current session signaling draft > "accidentaly" defines new protocol which is using the old DNS-RFC1035 as > "transport". > > I would welcome DNSbis effort with clear cut. Here please note that > clear cut does not mean that RR format and data, for example, has to be > incompatible! > > It is still possible to share big chunks of specifications (like RR > definitions, namespace, etc.) but define a DNSbis protocol which is > clearly distinguishable from the old DNS. > > Petr Špaček @ CZ.NIC > > > I'm starting to wonder whether a bof is needed. Maybe the IAB's > > workshop will produce some fruit? > > ___ > 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] I-D Action: draft-ietf-dnsop-session-signal-02.txt
On 20.7.2017 19:09, Andrew Sullivan wrote: > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: >>> But it's certainly another step along the way to DNSbis by accident. >> >> Would it be useful to make it not "by accident"? > > Yes. That was basically the point I was trying to make at the > beginning of today's session, about overall analysis. > > > b) make this draft DNS-SD only, so it can fast forward... >> > > I'm not keen on this. > > >> c) use the changed paradigm to work on DNSbis without the accident part? Yes please! My main opposition comes from fact that current session signaling draft "accidentaly" defines new protocol which is using the old DNS-RFC1035 as "transport". I would welcome DNSbis effort with clear cut. Here please note that clear cut does not mean that RR format and data, for example, has to be incompatible! It is still possible to share big chunks of specifications (like RR definitions, namespace, etc.) but define a DNSbis protocol which is clearly distinguishable from the old DNS. Petr Špaček @ CZ.NIC > I'm starting to wonder whether a bof is needed. Maybe the IAB's > workshop will produce some fruit? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
