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] 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] 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] NSEC/NSEC3 for unsigned zones and aggressive use
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). 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
Hi Jinmei On Wed, Jul 19, 2017 at 04:14:11PM -0700, 神明達哉 wrote: > At Tue, 18 Jul 2017 18:20:56 +0530, > Mukund Sivaraman wrote: > > > Dealing with water torture and some other attacks have had several > > band-aid approaches that don't always work well in practice. The most > > promising (and what feels correct) is > > draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned > > zones. > > Do you mean it's the most promising measure for authoritative servers? > If so, and if nsec-aggressiveuse is more widely deployed in resolvers, > and if the authoritative operators feel the pain so keenly, I'd rather > imagine they are willing to pay the cost of deploying DNSSEC. > > If you mean it's the most promising measure for recursive servers, I > simply don't buy the argument. (I made that comment while the wg > discussed nsec-aggressiveuse and it toned down quite a lot in that > sense as a result of it, so I believe it's based on a wg rough > consensus). I had meant only one of the benefits that nsec-aggressiveuse brings: * Avoid creating unnecessary fetches from the resolver by being able to answer more queries from cache (... ignoring the wildcard case.) It would help an auth service indirectly (if resolvers don't send it as many queries) but it has to handle the queries it gets. There are different approaches that are being used for handling water torture style attacks (bloom filtering with previously seen queries, fetches-per- controls, BLOOM RR type, etc.) but compared to those methods, NSEC aggressive use is a "correct" absolute method to stop fetches to non-existent names and data that works with minimal implementation changes only. A lot of popular zones are still unsigned. There are different reasons for it. Without advocating against DNSSEC, I want to point out that the all-or-nothing behavior of validation needs absolute correctness end-to-end in all pieces that some zone owners think about when considering whether to sign their zones. There are still implementation bugs. E.g., recently for several weeks/months, .ORG had a problem where it would not allow a DS record to be marked as removed. This meant that a child zone that wanted to go from signed to unsigned state could not do so (my own zones were affected). A zone signer implementation bug (e.g., untimely RRSIG generation causing no new RRSIGs to be added before existing RRSIGs expire) has the capability to take down all internet services at a domain. This still happens today, believe it or not. A zone owner has no control over schemes like using negative trust anchors at each resolver. There is the potential of significant economic loss to a business due to downtime that owners think about. Such frailty in the DNSSEC state of implementation has to improve before advocating DNSSEC as a solution to all problems. The fact that NSEC is a DNSSEC feature, and that it solves handling negative answer queries is a side-effect, but considering things individually, solving water torture style attacks doesn't need the rest of DNSSEC. It needs NSEC. (Please don't think that I'm advocating against DNSSEC. These are problems I come across practically as a programmer for a DNS implementation.) We have several popular unsigned zones today. It is the resolver side that has to answer for random non-existent subdomains under these zones. When talking about taking away the RRSIG of NSEC, it causes people to feel uncomfortable, but unsigned zones are unsigned after all. Whatever modification can be done by an attacker with an unsigned NSEC can be done right now too for individual queries. There should be more thought about benefit vs. risk of using such a scheme. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
At Tue, 18 Jul 2017 18:20:56 +0530, Mukund Sivaraman wrote: > Dealing with water torture and some other attacks have had several > band-aid approaches that don't always work well in practice. The most > promising (and what feels correct) is > draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned > zones. Do you mean it's the most promising measure for authoritative servers? If so, and if nsec-aggressiveuse is more widely deployed in resolvers, and if the authoritative operators feel the pain so keenly, I'd rather imagine they are willing to pay the cost of deploying DNSSEC. If you mean it's the most promising measure for recursive servers, I simply don't buy the argument. (I made that comment while the wg discussed nsec-aggressiveuse and it toned down quite a lot in that sense as a result of it, so I believe it's based on a wg rough consensus). So, either way, I don't see a strong case for the trick of using nsec-aggressiveuse on an unsigned zone with DNS cookies. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
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... > > 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 to rush on DNSSEC... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
On 18.7.2017 14:50, Mukund Sivaraman wrote: > Hi Paul > > On Tue, Jul 18, 2017 at 02:35:31PM +0200, Paul Hoffman wrote: >> On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote: >> >>> Will you give some thought and reply with your opinion on NSEC/NSEC3 for >>> unsigned zones requiring the DNS COOKIE option in transmission, that can >>> be used with draft-ietf-dnsop-nsec-aggressiveuse? >> >> Of what value is the result? Is it worth the hassle for the zone admin? > > It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned > zones. A zone admin would not have to do anything operationally except > enable/disable the feature. > > Dealing with water torture and some other attacks have had several > band-aid approaches that don't always work well in practice. The most > promising (and what feels correct) is > draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned > zones. For me this is an incentive to get more zones signed, not to add kludges just for unsigned ones. There surely are "operational and other reasons" not to sign zone associated with some cost. Signing and serving signed zone have cost_1 and serving unsigned zone has cost_2 (which needs to incorporate cost of attacks mitigated by DNSSEC). Eventually cost_2 of serving unsigned zone might get high enough so solving "operational and other reasons" might be cheaper than cost_1 paying for signing and serving signed zone. I would wait for that. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
Hi Paul On Tue, Jul 18, 2017 at 02:35:31PM +0200, Paul Hoffman wrote: > On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote: > > > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > > unsigned zones requiring the DNS COOKIE option in transmission, that can > > be used with draft-ietf-dnsop-nsec-aggressiveuse? > > Of what value is the result? Is it worth the hassle for the zone admin? It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned zones. A zone admin would not have to do anything operationally except enable/disable the feature. Dealing with water torture and some other attacks have had several band-aid approaches that don't always work well in practice. The most promising (and what feels correct) is draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned zones. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote: > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > unsigned zones requiring the DNS COOKIE option in transmission, that can > be used with draft-ietf-dnsop-nsec-aggressiveuse? Of what value is the result? Is it worth the hassle for the zone admin? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
Hi Francis On Tue, Jul 18, 2017 at 01:17:58PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > > There are still many popular unsigned zones, many of which don't look > > like they will be signed soon due to operational and other reasons. > > > > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > > unsigned zones requiring the DNS COOKIE option in transmission, that can > > be used with draft-ietf-dnsop-nsec-aggressiveuse? > > => I can't parse your message: > - unsigned zones have no zone keys 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). > - DNS cookie was designed to give a return routability proof for the client, > not the server > - there is no NSEC/NSEC3 in an unsigned zone > Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is > as usual required to avoid amplification DoS. This was discussed during the ISC 2017 all-hands; I don't remember if you were in the meeting when we discussed it (I think the meeting topic was about DoS mitigation measures). 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. > But what will be the signing key (including on the client side) and > what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative > servers of the (unsigned) zone? > It seems easier to remember that DNSSEC offers proofs for denial of existence. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
> On 18 Jul 2017, at 12:17, Francis Dupont wrote: > > It seems easier to remember that DNSSEC offers proofs for denial of existence. Except when it doesn't. :-) RFC5155 includes opt-in. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
Francis Dupont wrote: > It seems easier to remember that DNSSEC offers proofs for denial of existence. Yes. Surely we don't want to make the DNS even more complicated just to undemine one of the positive features of DNSSEC. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Southeasterly 5 to 7, occasionally gale 8 in west. Moderate becoming rough, occasionally very rough for a time in west. Rain later. Good, occasionally poor later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
In your previous mail you wrote: > There are still many popular unsigned zones, many of which don't look > like they will be signed soon due to operational and other reasons. > > Will you give some thought and reply with your opinion on NSEC/NSEC3 for > unsigned zones requiring the DNS COOKIE option in transmission, that can > be used with draft-ietf-dnsop-nsec-aggressiveuse? => I can't parse your message: - unsigned zones have no zone keys - DNS cookie was designed to give a return routability proof for the client, not the server - there is no NSEC/NSEC3 in an unsigned zone Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is as usual required to avoid amplification DoS. But what will be the signing key (including on the client side) and what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative servers of the (unsigned) zone? It seems easier to remember that DNSSEC offers proofs for denial of existence. Regards francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
