Re: [DNSOP] terminology: glue
Matthijs Mekking matth...@pletterpet.nl wrote: Personally I like to consider glue as a special type of occluded data (address records that are 'below' a zone cut). I think they are both different special cases of non-authoritative data in a zone. The key difference is that a name server will serve glue but it will not serve occluded records. Non-authoritative data can be: delegation NS RRsets (served in authority sections of referrals) glue (served in additional sections of referrals) occluded by a zone cut (not served) occluded by a DNAME (not served) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fisher: West 6 decreasing 4 or 5. Moderate or rough. Showers. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Upcoming P2PNames draft
WG Secretary hat on On May 7, 2015, at 9:47 AM, hellekin helle...@gnu.org wrote: I am definitely concerned with the fact that the P2PNames draft is not mentioned in [0] while draft-appelbaum-dnsop-onion-tld-01 was adopted by the WG, without any consideration for previous work, especially, as I mentioned before, with the existing incompatibilities between the two drafts. [0]: http://datatracker.ietf.org/wg/dnsop/documents/ This is an unfortunate misinterpretation of the display of that web page. Literally *none* of the drafts listed under Related Internet-Drafts are adopted by the WG. The listing in that section are really things that are considered related to the WG. There are two broad criteria for related to: - The filename for the draft contains the WG name between dashes - One of the WG chairs has figured out how to add a draft to the list Your draft didn't fall into either category, yet. That does not mean your draft isn't related to the WG, since your draft is clearly related by the fact it is on the agenda for an upcoming WG meeting, namely the virtual interim next week. --Paul Hoffman signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
In message d170e3e4.1011f2%jason_living...@cable.comcast.com, Livingood, Jas on writes: On 5/6/15, 2:07 PM, Suzanne Woolf suzworldw...@gmail.commailto:suzworldw...@gmail.com wrote: 2. In the particular cases of home/corp/mail, ICANN has studied the possibilities of name collisions, and decided not to delegate those names at this time. The proposal is that the IETF reserve those names for unspecified special use permanently. It seems that an IETF action on those names is redundant, unless it's in opposition to some action contemplated under ICANN policy (for which there is no apparent mechanism). Is the possibility of the same names considered under multiple policies a problem? home, corp and perhaps mail need special handling if we really want to not cause problems for those using those tlds internally. To do this there needs to be a insecure delegation to break the DNSSEC chain of trust. This will allow any server to filter leaked queries without causing validation failures. It will also allow DNSSEC validators to work without special knowledge of these tlds. By `redundant' do you mean the IETF should take no action? That seems to leave those names in a no-mans-land that could be problematic in the long-term, and the uncertainty could inhibit experimentation/investment in the home networking space. I'd rather see the IETF consider these names which are widely used and possibly add them to a new RFC, which then can be entered into and referred to from the IANA special-use domain name registry at http://www.iana.org/assignments/special-use-domain-names/special-use-domai n-names.xhtml Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
In message caje_bqc0unc6dtsjls8oeeka2mexxphbgijqaxfn7_awvq_...@mail.gmail.com , =?UTF-8?B?56We5piO6YGU5ZOJ?= writes: At Wed, 6 May 2015 18:33:24 +, Evan Hunt e...@isc.org wrote: Can someone explain why we'd need the separate error codes based on the position of supporting them (i.e, not to persuade others on dropping them)? msg13984.html was basically written to argue against them, so it could potentially and unintentionally be biased. I'll try to find any such explanation myself, but if someone already knows it better can do that, it would also help. Next by thread from msg13984 has Donald explaining his position, though not in great detail. If I understand him correctly, he wants to enable a server to include cookie errors even if it's chosen in this case to return an otherwise normal NOERROR response to the client. Okay, so it seems to be a case where the YAGNI principle can apply. On the other hand, on reading the draft and https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html more closely, I can see some not-so-trivial difference. Assume DNS cookies are deployed sufficiently and some operators start refusing queries without cookies. Then an attacker that wants to spoof a victim client (probably for an amplification attack) would send queries with an invalid server cookie anyway. According to Section 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server will still return the full size of response, so the attack will still be effective. On the other hand, a server implementation with the separate error code field can choose to send a minimal response with a valid server cookie according to Section 5.2.3 of the draft, thereby minimizing the risk of allowing amplification attacks while still allowing legitimate clients to bootstrap or re-synchronize. In the following part of msg13984.html: For (b) retrying should succeed. That said tc=1 would also be just as effective at triggering a retry. perhaps Mark tried to say we could achieve the same effect if the server returns a minimal size of response with TC bit on and with the correct server cookie. If it was his intent, it's true to some extent. But these two approaches are not entirely the same since using the TC bit has a side effect of forcing the use of TCP. Which gets the client/server what is needed for this and future transaction. It avoids the two denial of service senarios below. Just sending back BADCOOKIE leads to a potential denial of service with misconfigured anycast servers with differing shared secrets / server cookie algorithms. Just sending back NEEDCOOKIE leads to a potential denial of service when DNS COOKIE is not understood. Additionally a server can choose to send a minimal response rather than a full response or TC=1. In both cases it is a unverified query source and should be handled like all unverified query sources. I also have a hard time envisioning a client that supports DNS COOKIES not sending a DNS COOKIE by the time one could reliably send back NEEDCOOKIE and have it reliably acted on. The only reason for not sending a DNS COOKIE in the first place would be to handle broken EDNS servers and that is a solvable problem if everyone that depend on the DNS for their pay cheque does their bit to fix it. At the moment sending back NEEDCOOKIE would be equivalent to REFUSED and I don't see the equivalence changing. So the choice does not seem to be a no-brainer to me. But, in the end, I wouldn't be opposed to the idea of removing the separate error code field. The above difference wouldn't be so substantial anyway, and wouldn't justify the introduction of a generic error code field. One last point I'd like to make is that, assuming the above understanding of mine is correct, I'd suggest including the TC bit hack in the initial protocol description. Since it has a side effect it's better to have it sooner so we can update the spec if early deployments suggest the need for it. -- JINMEI, Tatuya ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/06/2015 03:07 PM, Suzanne Woolf wrote: Logistics details will follow shortly, but we have a webex URL *** As far as I understand, WebEx requires non-free software to work, which is a problem that will certainly make my participation more than difficult--as I do not have access to a system running such software. It's not the first time I notice that participation to Internet governance requires non-free software (e.g., in ISOC as well). Given that the process mentions XMPP, would it be possible to use that instead ? http://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/ http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-na mes/ *** I am concerned that the newer draft's IANA considerations are very different from the older one to the point that they might conflict. I already pointed that to the authors who seem to have ignored it. I feel it would be critical for them to lay down the reasons for which they introduced such incompatibilities that, to my reading, demote privacy considerations from primary to secondary concerns. == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVS3U5XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9jDYP/1QyuSygoVxMxH4RzhRbIryH 95ateC2fyKeGMTwAEZ6tv5JVPYqLlWhWG+gWeWIipgFzvy5U+IbbkfzrLroIz8jB E/1wHTTgdeSkRbgH8IYZAsqWOd7w5xdU3ZwxzvujwM771RBH96EU0DEHJZEOJhDS r/r4MAbr60lrzWRo41BPDPc+s6K1cJziLbiNC7g9fSVR1Xinow5cBZiPwY8lA3dl 9ahpjy3n1NGVQXFetxyUKjIV8SYdEVdhBp4ANYzwM+9CVoXQ7oo/LNkS6oOY7v5R dDKwAFBcPjQWYmFVZcUGE6huSu/gtJrzqKURTDs1OvZ5A+3vGnyhQMl6ysXUFfVr j/TrfIiIMfzgR3Nr+D1yEmp4su0XTk3WRDkzh8b7JW4kL8dlPdgninOgMSz6p8gK G/iVkUsRS95TdbSxql1Pm3YK1D2KGSIHxMMxIzOYtfk/Y6ZDIqcht76hHL4DP722 Gc0WGW5kUe1/VvJge12RGBU3CK5wzbcYBmFJcTgSH8vNuKEuRWog1vxlAg+lAObO YLC0ZwluBIXpGP6M9ZzRoIEbdlYw8j+/VtYxaGoPzAC4qi5BVD2cdf48HxgMYHHf L4JRicYHSqDzT9rwzH+EUSs3/okBaHy9vkRlgrZGDAdPFFwaiszAblGTnGf9qMHJ KLIO+tTMGVbR6eJmzGYY =hTUY -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
Beyond that, does it end up being a cheap way to avoid the ICANN process of creating a new gTLD. For example, I am not aware that anything prevents the ToR project from applying to ICANN for the .onion gTLD. ICANN has a whole bunch of rules that mandate that once you've paid the $185,000, you have to deploy a DNSSEC signed zone on multiple servers, implement elaborate reservation and trademark claiming rules, takedown processes, WHOIS servers, and so forth. In the recent TLD application round there was one applicant that only wanted to reserve the domain (they were apparently concerned that someone else would squat on .CONNECTORS) but they dropped out early so it's unclear what would have happened if they tried to move ahead. I was on one of the technical evaluation panels and I believe we failed them due to their lack of any plan to comply with the rules. THe only special purpose TLD that resolves globally is .ARPA, and everyone agrees what it does. The rest of them by design don't resolve globally. Some resolve locally (.local), some not at all (.test .example .invalid.) In this case, .onion falls on the IETF side of the line since it's definitely not supposed to resolve globally. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
At Wed, 6 May 2015 18:33:24 +, Evan Hunt e...@isc.org wrote: Can someone explain why we'd need the separate error codes based on the position of supporting them (i.e, not to persuade others on dropping them)? msg13984.html was basically written to argue against them, so it could potentially and unintentionally be biased. I'll try to find any such explanation myself, but if someone already knows it better can do that, it would also help. Next by thread from msg13984 has Donald explaining his position, though not in great detail. If I understand him correctly, he wants to enable a server to include cookie errors even if it's chosen in this case to return an otherwise normal NOERROR response to the client. Okay, so it seems to be a case where the YAGNI principle can apply. On the other hand, on reading the draft and https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html more closely, I can see some not-so-trivial difference. Assume DNS cookies are deployed sufficiently and some operators start refusing queries without cookies. Then an attacker that wants to spoof a victim client (probably for an amplification attack) would send queries with an invalid server cookie anyway. According to Section 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server will still return the full size of response, so the attack will still be effective. On the other hand, a server implementation with the separate error code field can choose to send a minimal response with a valid server cookie according to Section 5.2.3 of the draft, thereby minimizing the risk of allowing amplification attacks while still allowing legitimate clients to bootstrap or re-synchronize. In the following part of msg13984.html: For (b) retrying should succeed. That said tc=1 would also be just as effective at triggering a retry. perhaps Mark tried to say we could achieve the same effect if the server returns a minimal size of response with TC bit on and with the correct server cookie. If it was his intent, it's true to some extent. But these two approaches are not entirely the same since using the TC bit has a side effect of forcing the use of TCP. So the choice does not seem to be a no-brainer to me. But, in the end, I wouldn't be opposed to the idea of removing the separate error code field. The above difference wouldn't be so substantial anyway, and wouldn't justify the introduction of a generic error code field. One last point I'd like to make is that, assuming the above understanding of mine is correct, I'd suggest including the TC bit hack in the initial protocol description. Since it has a side effect it's better to have it sooner so we can update the spec if early deployments suggest the need for it. -- JINMEI, Tatuya ___ 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 May 7, 2015, at 9:56 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: Beyond that, does it end up being a cheap way to avoid the ICANN process of creating a new gTLD. For example, I am not aware that anything prevents the ToR project from applying to ICANN for the .onion gTLD. So from one perspective, would more people just deploy into an unused namespace and then later lay claim the the namespace retroactively based on their use (gTLD-squatting)? This could be quite messy at scale, and I am not sure the IETF has a process to deal with and consider competing uses. I think this is an unfortunate way to look at the issue. We have a clear process for allocating special-use domain names. If TOR had come to us and asked for one, would you argue that they should pay ICANN $180k to get it? Where would that money come from? They don't need a delegation. They just need for the name to be registered as a special-use name. This is not at all the same situation as someone coming to us asking to get a _delegation_ for a TLD based on the special-use domain name process. Special-use doesn't apply in that case, and we would reject it. So your argument amounts to a straw man. I think part of the reaction to this proposal at the moment is that the process _wasn't_ followed. And so we are rightly concerned that future candidates for special-use names will also not follow the process, leading us to have to revisit this conversation. However, that is actually exactly wrong. In reality, the more pushback we give for a reasonable and legitimate request for a special-use domain now, the more likely it is that when someone needs one in the future, they will give up before they try, as the ToR people did. What we should be doing is judging those requests that seem legitimate and responding expeditiously, not creating a huge process black hole into which such requests will be swallowed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Upcoming P2PNames draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The authors of draft-grothoff-iesg-special-use-p2p-names are about to release a new version of the P2PNames draft that integrates the comments we've received from the P2P systems community. Unfortunately, the previous draft didn't receive much attention from the DNSOP WG yet, so if you have additional remarks on this specific version, please do so. I am definitely concerned with the fact that the P2PNames draft is not mentioned in [0] while draft-appelbaum-dnsop-onion-tld-01 was adopted by the WG, without any consideration for previous work, especially, as I mentioned before, with the existing incompatibilities between the two drafts. Currently we have two conflicting interpretations of IANA considerations for the adoption of .onion, one that was inserted in the DNSOP WG process by way of chutzpah, and one that is actually concerned with privacy, but was left pending because it means to cover a logical surface for all known P2P systems at this time who are willing to collaborate. == hk [0]: http://datatracker.ietf.org/wg/dnsop/documents/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVS5ckXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9FNoQALPJnAVdRJSneoZhp82yL+QH pNSsFsTQXS/h30pknYXqjVHzum6lluxtwHLV02xI28tQS4XfOJq0hwx5CC+rU3x1 xudbxTaM3mZzCyRTMxQnlaPb7HKlV/soC/rTpbrtcvLPnrMx9MOptoLyh/qvd46U p1b3pAnKchFmSpfqyV5w6wU9SqXb5BDoPSftpHXNkHPZ1opzh3RlBKEPz3nCoo73 /MfhqiyRuF1wKfWOpIuSIsXURQ/8HUuAZsh2K7w4I/lMluasuRfhLyoOkOd/0vVp PNMBgvUsI97BQYIar6jpNB6R6Xb16VWQFk6XfHghPD8XGyCHL/lNux8sULSYqW6h PrvpJeBjb85y6aq1ozBC4LSm0dAu5CMZgTi0JiGgek1HKPFifcgnrv7c6Q2oRUKm 5GFs8hfMHL4qkfVecPW0nbnehfmAMCPkzPwvJKSaJNrHrwlaFNE6tb5L3DGBf6WN r1nDwT6tY4zu0zBteRiHe4bS5xVP76UYUCxahNkm339qFYuD1wczItfUXwrccxD4 BygArpA9DDopGVRYDlAoFWZAKnBDpCEmKPq00ERMr0itqVv4x9avxh8shr8U/HQy bCxR5jnKF0iQHqXlA7zELrTicxMt+kysFkv4VBizSj4vk/vZ9kuYwEzkpbVgDnCg JxQP0E7Vl+LOZJqDR6y+ =Ay6L -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01
On Thu, May 07, 2015 at 09:11:53AM -0700, 神明達哉 wrote: According to Section 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server will still return the full size of response, so the attack will still be effective. Subject to rate limiting restraints, yes. BIND's experimental SIT implementation exempts clients from rate limiting if they have a valid cookie, but not otherwise. The cookie is more of a way for legitimate client traffic to be privileged, than for attack traffic to be mitigated; we have other mechanisms in place to handle mitigation. That said, however, I like the idea of adding the TC=1 response to the protocol specification as a MAY. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
