Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
Does this mean: A: All implementations that conform to this document should prefer the NTA over the positive anchor in such a case, or B: This is implementation-dependent, but if an implementation allows the coexistence of positive and negative anchors, it should prefer the NTA, or C: something else? Good point. I personally favor A, but would be fine with B. I'd be interested in input from other implementors; if there's a constituency for B then fine, but if we're all going to allow coexistence anyway, we might as well specify it that way. I don't have a strong opinion between A and B, but I'd like this document to be clear on this. And, if it means A, I'd use an RFC2119 keyword (it's probably a SHOULD). With respect to the precedence rule, I would use MUST rather than SHOULD. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] A comparison of IANA Considerations for .onion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Since Alec Muffett seems to have better things to do, I feel obligated to do what he should have done before publishing his draft: comparing the IANA Considerations for .onion in the draft-grothoff-iesg-special-use-p2p-names-04 (P2PNames) and draft-appelbaum-dnsop-onion-tld-01 (OnionTLD). # OVERVIEW draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the processing of .onion special-use TLD, as the P2PNames draft was considered too controversial (and maybe too complicated?). But this work, although sporting the name of a co-author of the P2PNames draft and claiming support by the Tor Project community, did not benefit neither from concerted action with, nor consideration for the existing w ork. A simple comparison of the IANA Considerations for the P2PNames and the OnionTLD drafts highlights critical flaws in the OnionTLD draft that curiously didn't receive any attention at all so far (except my own, but I reserved my comments up until now for others to come up with this, in vain.) I noticed 3 major issues in the OnionTLD draft: 1. the users considerations pretend that users must use onion-aware software in order to access Onionspace, but I assert that you and I can use an ordinary Web browser, type in a .onion address, and access the requested service. Not only OnionTLD conflicts with P2PNames on that point, it also confuses users' awareness and application software responsibility (and possibly the scope of IANA Considerations' first question). 2. more importantly, where P2PNames imposes NXDOMAIN response to authoritative name servers, OnionTLD makes it a soft requirement, thus leaving the possibility for name servers to hijack Onionspace without user consent nor awareness. 3. this error is confirmed for DNS server operators, where OnionTLD makes it a soft requirement not to override responses. Given the complementarity of 2. and 3. for successful dragnet abuse, I have difficulty believing in a coincidence, and am very concerned that such points could go through an IETF process without an itch. That the P2PNames draft remains controversial should not remove from its qualities, and notably its technical fitness and attention to detail. As the editor of this draft, I apologize for the shameless self-promotion and urge the DNSOP WG members to not confuse diligence and precipitation. # IANA CONSIDERATIONS DETAILS This verbose section details point by point the differences and put them in context with RFC6761 questionnaire. ## 1. Users - From RFC6761: Are human users expected to recognize these names as special and use them differently? In what way? * The OnionTLD interpretation is wrong. I want for proof that I can browse Onionspace with an ordinary Web browser that does not treat .onion sites any differently from a .org or a .net. The OnionTLD interpretation also contradicts the P2PNames interpretation, and pushes responsibility to the users (who should know what they're doing). Moreover, the OnionTLD interpretation also says that onion addresses are only available through [onion-aware] software, which is not the case. * P2PNames says: Users can use these names as they would other domain names, entering them anywhere that they would otherwise enter a conventional DNS domain name. Since there is no central authority necessary or possible for assigning .onion names, and those names correspond to cryptographic keys, users need to be aware that they do not belong to regular DNS, but are still global in their scope. OnionTLD contradicts this: Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. ## 2. Application Software - From RFC6761: Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?) * The OnionTLD interpretation only covers the case of onion-aware applications, and then do not specify the response. * P2PNames says: Application software MAY recognize .onion domains as special, and SHOULD use these names as they would other domain names. Application software MAY implement mechanisms helping the user to ensure their privacy expectations are met, such as warning the user if they do not detect an active local Tor resolver, displaying a warning on first-use of an .onion domain to explain the necessity of a Tor resolver to reach such domains, etc. If an application knows how to differenciate between DNS and P2P name resolution, it: * SHOULD NOT pass requests for .onion domains to DNS resolvers or libraries, * MUST expect NXDOMAIN as the only valid DNS response, and * SHOULD treat other answers from DNS as errors. Tor-aware applications MAY also use Tor resolvers directly.
Re: [DNSOP] A comparison of IANA Considerations for .onion
Hi there, On Mon, May 11, 2015 at 06:15:47PM -0300, hellekin wrote: draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the processing of .onion special-use TLD, as the P2PNames draft was considered too controversial (and maybe too complicated?). As one of the people who has objected to the p2pnames draft, I would say that appelbaum-dnsop-onion is an attempt to break out one of the candidate special names from the others, so that all the applications don't share fate. A simple comparison of the IANA Considerations for the P2PNames and the OnionTLD drafts highlights critical flaws in the OnionTLD draft that curiously didn't receive any attention at all so far (except my own, but I reserved my comments up until now for others to come up with this, in vain.) Well, they're different drafts, and therefore it's not completely surprising that they don't agree. I suspect part of the issue here is that appelbaum-dnsop-onion has been adjusted because of some comments some of us made. 1. the users considerations pretend that users must use onion-aware software in order to access Onionspace, but I assert that you and I can use an ordinary Web browser, type in a .onion address, and access the requested service. Not only OnionTLD conflicts with P2PNames on that point, it also confuses users' awareness and application software responsibility (and possibly the scope of IANA Considerations' first question). I've asked about this issue several times, and I keep getting different answers. What isn't clear to me is whether there is somewhere in the user's stack -- maybe it's the resolver, maybe it's the application, whatever -- that knows that onion is special and therefore shouldn't be looked up in the public DNS. I assume there has to be _somewhere_ that is special, or the alternative resolution obviously wouldn't work. I think that needs to be indicated somewhere, because this fact is what makes onion a candidate under 6761, I think. 2. more importantly, where P2PNames imposes NXDOMAIN response to authoritative name servers, OnionTLD makes it a soft requirement, thus leaving the possibility for name servers to hijack Onionspace without user consent nor awareness. Yes. That is in fact a possibility. There is no way for a protocol document to make it impossible for someone to redirect this name, and if your queries for onion leak into the public DNS you have to be prepared for the possibility that someone will provide a local answer. It's a plain fact of working on the Internet, and trying to legislate this in a protocol document provides inoperative assurances. In fact, the way that onion was deployed without a registration with the policy authority over the root zone rather nicely illustrates this fact about the DNS: the global DNS only works because everyone uses the same root. If people start fraying that use, then the DNS itself is in trouble. 3. this error is confirmed for DNS server operators, where OnionTLD makes it a soft requirement not to override responses. But again, you simply can't legislate that. People do this all the time. Indeed, some people pay for services in which the answers from their resolvers are munged to prevent access to bad sites and so on. You could make this sort of fiddling with the data possible to detect using something like DNSSEC, but you can't make it impossible to do. That the P2PNames draft remains controversial should not remove from its qualities, and notably its technical fitness and attention to detail. Issues 2 and 3 were problems with the p2pnames draft when it first surfaced, and I believe I included them in the comments I sent on it in the first place. If I didn't I apologise. The OnionTLD interpretation is wrong. I want for proof that I can browse Onionspace with an ordinary Web browser that does not treat .onion sites any differently from a .org or a .net. Well, surely _this_ isn't what you want, because if that were the case then the onion TLD would fail to resolve at all, since it isn't delegated. OnionTLD contradicts this: Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. But the point is, you need to know whether you have an onion-aware resolution path available, or else you will leak your queries to the public DNS. I think that's all it says. OnionTLD says: Application Software: Applications that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly, or using a proxy (e.g., SOCKS [RFC1928]) to do so. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion, and SHOULD NOT perform a DNS lookup. What's the problem with this? Isn't this what you want, that the onion queries don't leak? * In P2PNames, immediate negative responses is not specified yet (for lack of discussion
Re: [DNSOP] A comparison of IANA Considerations for .onion
On Mon, May 11, 2015 at 7:21 PM, Alec Muffett al...@fb.com wrote: Hi Hellekin! Since Alec Muffett seems to have better things to do I'm sorry if you've been waiting for my input - I am not the primary author of the document; Jacob Appelbaum's name is in the document's title for a good reason, and my involvement has been one of tuning a few paragraphs, providing some wordsmithing, and cheerleading loudly. Jake is - as I am sure you are aware - working for Tor, and is a busy guy (last I heard was off in China doing something amazing) hence I mailed out the latest draft when there was in extended (and ongoing) lull in the desire for anyone on our editorial maillist to tweak it. I'll do my best to respond to your points, albeit Jake and other (wiser?) heads may have additional insights that I may miss by dint of this being dropped on me at 10pm the night before the big phone call to discuss such matters. On that basis, you'll also please forgive me excising brevity. 1. the users considerations pretend that users must use onion-aware software in order to access Onionspace, but I assert that you and I can use an ordinary Web browser, type in a .onion address, and access the requested service. If you are consciously running TAILS, I suppose so [ED: TAILS is a Linux distribution which funnels almost all communication through Tor] albeit that Tor would likely recommend against using a vanilla browser in default configuration to access any part of Tor, let alone .onion addresses, because risk of deanonymisation is too high with normal browsers. Hence the imprecations in favour of informed users, reflecting Tor user-policy. If you are not talking about running TAILS (or similar) then I must be misapprehending what you mean by can use an ordinary Web browser, type in a .onion address, and access the requested service because your average browser - say Chrome - cannot access .onion without Tor software help and some fiddly configuration. 2. more importantly, where P2PNames imposes NXDOMAIN response to authoritative name servers, OnionTLD makes it a soft requirement, thus leaving the possibility for name servers to hijack Onionspace without user consent nor awareness. Yeah, we tossed that one back and forth a bit, and eventually if slightly grudgingly went with the SHOULD on the basis that we wanted the draft to be adopted more than we wanted to be thinking wishfully. 3. this error is confirmed for DNS server operators, where OnionTLD makes it a soft requirement not to override responses. This might be an issue so long as your threat model includes blindly unaware users who are typing .onion addresses into non-Tor-capable browsers in the (presumably first-time) expectation that it will work, and using resolver libraries which don't honour the imprecation that: [draft-appelbaum-dnsop-onion-tld-01] Resolvers that implement theTor protocol MUST either respond to requests for .onion names by resolving them (see [tor-rendezvous] [ED: A TOR-INTERNAL THING]) or by responding with NXDOMAIN. ...on a network infrastructure which is thoroughly pwned by a capable bad actor. Not totally impossible, I'll grant you, but threat models which start from the assumption of a wholly ignorant userbase are (joking aside) pretty flawed. Continuing... [DELETIA] Since there is no central authority necessary or possible for assigning .onion names, and those names correspond to cryptographic keys, users need to be aware that they do not belong to regular DNS, but are still global in their scope. OnionTLD contradicts this: Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. Please explain the contradiction, I fail to see it? [DELETIA] This is the main conflicting point: OnionTLD does not recognize .onion as special and allows Authoritative DNS servers to respond for .onion (SHOULD). From the P2PNames perspective, this is unacceptable, and a complete failure to address the privacy concerns set forth by the draft. If OnionTLD would be accepted in that form, it would allow the root servers to capture leaked onion requests AND RESPOND POSITIVELY FOR THEM ! * There are entire papers about that. Thank you for raising that point, I wanted an excuse to post this URL to the DNSOP list: https://petsymposium.org/2014/papers/Thomas.pdf Measuring the Leakage of Onion at the Root - A measurement of Tor’s .onion pseudo-top-level domain in the global domain name system ...to help drive home the need for making .onion special. To save some time, the headline number is: The rate of .onion requests hitting the A and J roots is ~200k requests per day and growing. --Richard As before, ignoring the potential for privacy-leakage of which site you are
Re: [DNSOP] A comparison of IANA Considerations for .onion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/11/2015 08:21 PM, Alec Muffett wrote: This might be an issue so long as your threat model includes blindly unaware users who are typing .onion addresses into non-Tor-capable browsers in the (presumably first-time) expectation that it will work *** You probably mean to say: human beings. ...on a network infrastructure which is thoroughly pwned by a capable bad actor. *** You probably mean: the Internet. Please explain the contradiction, I fail to see it? *** How can you fail to see that P2PNames says Users can use these names as they would other domain names, while OnionTLD says they cannot ? As before, ignoring the potential for privacy-leakage of which site you are seeking to connect to, this notion of ZOMG THEY COULD HIJACK THE SITE is not a problem if you're using Tor-enabled software and have awareness of the issue, per the draft security considerations. *** So you recognize that if your Tor setup is wrong, and you're not aware of this, then it could happen that a malicious entity could serve a copy of the original site, but resolved over the DNS. This to me, sounds like the well-documented--not hypothetical--abuses of NXDOMAIN that were historically performed by Verisign, Comcast, and others. Are you sure you still don't see any difference at all between MUST and SHOU LD? == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVUUlGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg962AP/0A7YE1UslDCKctnm2CRC39V OMIPlVRITQNyAXE7FlqFL5W1PoebmZZsU5ITFiTUXnsPEonPon4KU9ZbGkFVhZ0q BQdGL77d1F6dCzBX0E50ePaBgiwFVS4mqIdNH0QWIgk4iE+3pduLP5kZSZcFzvuJ OWy/sOCZMdBdCUzV13Rg7UzYql89uYFGpg6o8Ti7AkdQM2soGdkht6mx/s4kN7qJ BE2JpXbgKvyYwlwx5J6kvwhN2tnhIDWFLGRZ3U6pqHZXaI9QvzfoLaFm/for7Ha6 psjBirbqXJ5/+PPv2qt0ad4sJCBE3FFknLL+c4zDWGWo8ReiqOjDJ2yc1Jru31Lu a7EOejrv6Oor/owFBEIElzI/X4gdnwpuA5P4GSTFnjartAPzn98aylTC3S0GZwAe KudvUZABkQOOE/jTGGckYRYPmcQhOUXz4dfWQ2ZismYVEoNzqQFLrfU+6GmlkY4X Im70HVL5i72LMljuphlfForu8XPDdl0/uTPra6mE65cA9Wf85PBenbSd/YKGd33b Z+LxReRj5Q5l8+nDyQZJNqadadwPdsvPh4WknBDbio7CpX86bBHfNA4xEHe/lUGr J6k8KQ1SRilOfDF/9U7REQwQ3J3LSzTIObGxvtxtgJ3txRNzt+PmSbIiuApYrwj+ l6Vq+UOxnV7rCEHEjoOl =/L7B -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
On Fri, May 08, 2015 at 08:10:41PM -0700, Paul Hoffman wrote: - Will the IETF require some specific metrics for RFC 6761 reservations? - If yes, what are those metrics? - If no, who makes the non-specific decision? Increasingly it strikes me that RFC 6761 is trying to do too much. It was, as we all know, created as a _post hoc_ rule to permit the creation of local, on which Apple squatted to create Bonjour. That was one particular use of a namespace: the namespace amounts to a protocol-shifting mechanism. We can expect to see this again (and indeed, several of the names that are in the p2pnames draft are effectively in this class). In order to create that set of rules, however, the special use names registry came about. That registry includes all sorts of other special-use names that are in fact reserved for _policy_ reasons. For instance, example, test, and invalid are there because of the policy of needing certain names for testing, documentation, and so on. Similar arguments can be made about the RFC1918 addresses in arpa: these are special only because of a different policy decision to reserve chunks of v4 space for local use. The interesting case is localhost, which I think might have elements of each of these properties, though because of the binding to the 127.0.0 network you might be able to argue that the policy is actually elsewhere. It seems to me that making new reservations solely on _policy_ grounds is overstepping our role, because we actually gave that management function away to someone else many years ago. But if there are additional protocol-shift registrations, it would be appropriate to do that. This makes me think that what we ought to offer ICANN is a mechanism to make insertions into the special-names registry by different criteria than the protocol-shift cases. The latter all fit neatly into 6761's 7 questions, but policy-based ones sort of don't. Anyway, that's a suggestion. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A comparison of IANA Considerations for .onion
On Mon, May 11, 2015 at 09:29:02PM -0300, hellekin wrote: *** How can you fail to see that P2PNames says Users can use these names as they would other domain names, while OnionTLD says they cannot ? I think people can see that, and they disagree with you. If you put an onion name into an application and your system (somehow) is onion-aware, it will behave differently than if it is onion-unaware. If you put a com name into an application, it Just Works, because DNS resolvers are basically universal. That's an important difference. (Note that I picked com on purpose. Ask the users of info domains how many problems they still have, 14 years after that TLD was first delegated.) *** So you recognize that if your Tor setup is wrong, and you're not aware of this, then it could happen that a malicious entity could serve a copy of the original site, but resolved over the DNS. This to me, sounds like the well-documented--not hypothetical--abuses of NXDOMAIN that were historically performed by Verisign, Comcast, and others. Are you sure you still don't see any difference at all between MUST and SHOU LD? Not every network is a public-access one. For instance, there might be a local policy at my employer that onion names are not to be resolved. I can certainly imagine them installing a resolver that captured and redirected onion resolution attempts. (That is not, of course, a policy at _my_ employer, but I can imagine such a case without trouble.) Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A comparison of IANA Considerations for .onion
Hi Hellekin! Since Alec Muffett seems to have better things to do I'm sorry if you've been waiting for my input - I am not the primary author of the document; Jacob Appelbaum's name is in the document's title for a good reason, and my involvement has been one of tuning a few paragraphs, providing some wordsmithing, and cheerleading loudly. Jake is - as I am sure you are aware - working for Tor, and is a busy guy (last I heard was off in China doing something amazing) hence I mailed out the latest draft when there was in extended (and ongoing) lull in the desire for anyone on our editorial maillist to tweak it. I'll do my best to respond to your points, albeit Jake and other (wiser?) heads may have additional insights that I may miss by dint of this being dropped on me at 10pm the night before the big phone call to discuss such matters. On that basis, you'll also please forgive me excising brevity. 1. the users considerations pretend that users must use onion-aware software in order to access Onionspace, but I assert that you and I can use an ordinary Web browser, type in a .onion address, and access the requested service. If you are consciously running TAILS, I suppose so [ED: TAILS is a Linux distribution which funnels almost all communication through Tor] albeit that Tor would likely recommend against using a vanilla browser in default configuration to access any part of Tor, let alone .onion addresses, because risk of deanonymisation is too high with normal browsers. Hence the imprecations in favour of informed users, reflecting Tor user-policy. If you are not talking about running TAILS (or similar) then I must be misapprehending what you mean by can use an ordinary Web browser, type in a .onion address, and access the requested service because your average browser - say Chrome - cannot access .onion without Tor software help and some fiddly configuration. 2. more importantly, where P2PNames imposes NXDOMAIN response to authoritative name servers, OnionTLD makes it a soft requirement, thus leaving the possibility for name servers to hijack Onionspace without user consent nor awareness. Yeah, we tossed that one back and forth a bit, and eventually if slightly grudgingly went with the SHOULD on the basis that we wanted the draft to be adopted more than we wanted to be thinking wishfully. 3. this error is confirmed for DNS server operators, where OnionTLD makes it a soft requirement not to override responses. This might be an issue so long as your threat model includes blindly unaware users who are typing .onion addresses into non-Tor-capable browsers in the (presumably first-time) expectation that it will work, and using resolver libraries which don't honour the imprecation that: [draft-appelbaum-dnsop-onion-tld-01] Resolvers that implement theTor protocol MUST either respond to requests for .onion names by resolving them (see [tor-rendezvous] [ED: A TOR-INTERNAL THING]) or by responding with NXDOMAIN. ...on a network infrastructure which is thoroughly pwned by a capable bad actor. Not totally impossible, I'll grant you, but threat models which start from the assumption of a wholly ignorant userbase are (joking aside) pretty flawed. Continuing... [DELETIA] Since there is no central authority necessary or possible for assigning .onion names, and those names correspond to cryptographic keys, users need to be aware that they do not belong to regular DNS, but are still global in their scope. OnionTLD contradicts this: Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. Please explain the contradiction, I fail to see it? [DELETIA] This is the main conflicting point: OnionTLD does not recognize .onion as special and allows Authoritative DNS servers to respond for .onion (SHOULD). From the P2PNames perspective, this is unacceptable, and a complete failure to address the privacy concerns set forth by the draft. If OnionTLD would be accepted in that form, it would allow the root servers to capture leaked onion requests AND RESPOND POSITIVELY FOR THEM ! * There are entire papers about that. Thank you for raising that point, I wanted an excuse to post this URL to the DNSOP list: https://petsymposium.org/2014/papers/Thomas.pdf Measuring the Leakage of Onion at the Root - A measurement of Tor’s .onion pseudo-top-level domain in the global domain name system ...to help drive home the need for making .onion special. As before, ignoring the potential for privacy-leakage of which site you are seeking to connect to, this notion of ZOMG THEY COULD HIJACK THE SITE is not a problem if you're using Tor-enabled software and have awareness of the issue, per the draft security considerations. [DELETIA - I WANT TO GO TO BED I HAVE A VERY LONG DAY TOMORROW] Your conclusions mostly seem to be a
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
At Sat, 9 May 2015 15:08:11 +0200, Warren Kumari war...@kumari.net wrote: 1. In my very original comment on this matter: www.ietf.org/mail-archive/web/dnsop/current/msg12614.html I noted one other corner case, which we might also want to clarify: On a related note, there are some corner cases which may also be worth noting: queries for DS or DLV (or anything similar to that). So, for example, zone1.example.com/DS should still be validated even if there's an NTA for zone1.example.com. Again, this might sound obvious, but I think it's worthwhile. I have spent some time trying to figure out some text that explains this without becoming really complex and wordy. If anyone has some text that they would be willing to send I'd appreciate it... I didn't think we'd need wordy text to explain this, but I wouldn't be opposed to omitting this topic from this document. In practice, it wouldn't matter much whether we validate zone1.example.com/DS in the example case since everything else on and under zone1.example.com won't be validated anyway. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
On Mon, May 11, 2015 at 12:10 PM, 神明達哉 jin...@wide.ad.jp wrote: At Sat, 9 May 2015 18:50:28 +, Evan Hunt e...@isc.org wrote: Actually, weirdly enough, after I implemented NTA's in BIND, one of the very first applications somebody came up with for them was to temporarily disable DNSSEC validation by setting an NTA for .. This was seen as better than rndc validation off because he didn't have to send rndc validation on afterward; it would just quiety switch itself back on after a minute. It's... actually a pretty clever hack, and I don't really want to disable it. May I suggest: An NTA placed at a node where there is a configured positive trust anchor takes precendence over that trust anchor, effectively disabling it. Implementations MAY issue a warning when this occurs. Does this mean: A: All implementations that conform to this document should prefer the NTA over the positive anchor in such a case, or B: This is implementation-dependent, but if an implementation allows the coexistence of positive and negative anchors, it should prefer the NTA, or C: something else? I don't have a strong opinion between A and B, but I'd like this document to be clear on this. And, if it means A, I'd use an RFC2119 keyword (it's probably a SHOULD). -- JINMEI, Tatuya I think A is the right answer. Otherwise you run into situations where you need an NTA, but it won't work. I am not even sure there is a good reason for a warning. The zone is supposed to be signed, but the signing is broken, and the resolver operator has determined that it is due to a mistake, and decided to apply an NTA, same as any other situation. Whether the signing comes from the root or a positive anchor seems irrelevant to me. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
On Mon, May 11, 2015 at 12:19:19PM -0400, Bob Harold wrote: I am not even sure there is a good reason for a warning. In BIND, NTA's are set by an rndc command, but in other implementations they might be set up in a config file. If you have both a TA and an NTA for the same node in the same configuration, that would be sensible to warn about; it's the sort of oddity that might have been unintentional. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
At Sat, 9 May 2015 18:50:28 +, Evan Hunt e...@isc.org wrote: Actually, weirdly enough, after I implemented NTA's in BIND, one of the very first applications somebody came up with for them was to temporarily disable DNSSEC validation by setting an NTA for .. This was seen as better than rndc validation off because he didn't have to send rndc validation on afterward; it would just quiety switch itself back on after a minute. It's... actually a pretty clever hack, and I don't really want to disable it. May I suggest: An NTA placed at a node where there is a configured positive trust anchor takes precendence over that trust anchor, effectively disabling it. Implementations MAY issue a warning when this occurs. Does this mean: A: All implementations that conform to this document should prefer the NTA over the positive anchor in such a case, or B: This is implementation-dependent, but if an implementation allows the coexistence of positive and negative anchors, it should prefer the NTA, or C: something else? I don't have a strong opinion between A and B, but I'd like this document to be clear on this. And, if it means A, I'd use an RFC2119 keyword (it's probably a SHOULD). -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
