Re: [DNSOP] Some distinctions and a request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andrew Sullivan wrote: On Tue, Jun 30, 2015 at 11:43:42AM +, Edward Lewis wrote: I'm not aware of the rule that declares Onion names as part of the domain name space. Not an argument, just a data point. I've always heard, and have been running on this, that Onion names are not part of the DNS name space. You're conflating DNS name space and domain name space again. I didn't say they're part of the DNS name space; and given what the top-level label onion. does, they can't possibly be. At the beginning, I claimed that the domain name space was all the logically possible domain names, not all the ones in fact possibly in the DNS. Under this definition, local. is part of the domain name space and not part of the DNS name space (because of local. being registered in the special use names registry). When I asked about this before, one of the onion proponents told me that onion names have to conform to DNS (and, he claimed, LDH) rules right now, though that is a possibly temporary convention. .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. In some future where the percentage of apps requiring this is much lower (by most apps natively supporting Tor/I2P/etc), the restriction could be removed. But while domain names are the de-facto standard, I don't see it changing. Alain Durrand and I talked about this a few weeks back. He made the point that you can distinguish the namespace of an identifier on the right or on the left imaging the use of names in URLs. I.e., there could be a http-tor://tor-name.onion/path and use http-onion to tag this as a Tor identifier or http://tor-name.onion/path; and assume it's Tor because of the onion where I'd expect(*) a domain name to be. I think this is a terrible confusion of URI schemes vs. name-space switches. It's true that if you treat the URI as an unformatted string you can parse it this way; but there are already rules for that. But I think anyway that's a distraction. We don't need uri-schemes to creep into this. +1. Besides the confusion, this would require native app support, because URI schemes are generally handled separately to name resolution - you couldn't just use a SOCKS/HTTP/DNS proxy to handle legacy applications, like Tor/I2P/GNUnet do now. str4d Best regards, A -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVk371AAoJEBO17ljAn7PgmpgP/RXlwq9LVkKCkY8Ldk/QMo2z zFc2P1E7mO2JmNrkt4d77l+mzWNz3Ne0LMRen5mnJMvl+LitsF62kM3DJ+J9P0EZ 9MFt+WkpkYa+Jz1pMvTaR18Z5uZg8MAJB/qui/0xpTx2FPg02aNWyeroS32nX5Lo TCx4YgVxBdQYKjXzg9t57+5t+CgcNVu9/YBVuJfEj+Isu/GZHr4ElstVtVrv50zq 1U3UycHA9HWdTjKU1zE6f3IrZXIzNpQGDXwjdhYySpGK1nKwTVRBEJFDsz2JDtyc fu8gVsMPvvmqDwDYOJCqxvB5Ko/bF2PehtdtGY82qJBdtE5w+/Rbtu5mdZeupcU3 Ps74fZk6zHEZzzbbJjvwDHHG4oE/AmhLRZp9fylhzabCCElGNZ8Uuc4Fz7ZuXFsn ngg+9ANVl10JFv+RkKjKEbyyoUKDvd69d7TxAv11wR+OIhnchCFFRyU3YVlEuuK5 g5WMCQyhb010Wa5QasoQH2OAlhKQPsDtN2WbLoljqyptmIJ4TU2dej/EJSYSvX1M kbkj005GFm0jv4rVRja7dgkmrErxH9tJq0HwcIsQPe+KaIHWmeR2BwTbxXiQtjBr gb6bGc5EO1GakxARefvHSLjag/iFuOjJ8M6kU8IKb2gemzXpOPA4ocfF3GwajcXi +uWyxB0slKYUiBUNxFzw =67PO -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On Wed, Jul 1, 2015 at 10:08 AM, Suzanne Woolf suzworldw...@gmail.com wrote: Ed, First-- apologies for the misunderstanding. On Jul 1, 2015, at 9:53 AM, Edward Lewis edward.le...@icann.org wrote: Trying to be more clear, I have in the past imagined that today someone is inventing a new communications technology, in 6 months will need to cobble an identifier space and in 2 years the IETF-connected crowd detects significant deployment of this and needs to decide whether to register a TLD to avoid name collisions. I've been told that this wouldn't happen because the IETF will have rules - which I am skeptical would prevent the situation from happening. I don't think we have rules or even guidelines now that have any chance of preventing it. I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first. But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. Warren points at ALT-TLD Yup, we will not be able to prevent people from using an identifier space that looks like a DNS name not rooted in the DNS, but we *can* provide them with guidance and a safe place to do this sort of thing, namely under the .alt TLD. To underscore - I am not against the innovation. I am urging that the processes put in place are future proof by being reactionary - reacting to the new names, not trying to fend off the situation. I.e., in agreement with the words below trying to apply RFC 6761 and finding that it remains subjective. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? I believe so, but instead of simply raising the bar to get a special use name (which will simply result in people squatting more), I think we need to provide solid, usable advice and an option for people... W thanks, Suzanne On 7/1/15, 9:05, Suzanne Woolf suzworldw...@gmail.com wrote: (no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP can comment on is how the DNS reacts to names, whether in protocol or operational convention, once they are known before they achieve some degree of widespread adoption. To what extent is an effort made (by whomever) to detect these budding namespaces, is this proactive?
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On Wed, Jul 1, 2015 at 2:23 PM, Warren Kumari war...@kumari.net wrote: On Wed, Jul 1, 2015 at 10:08 AM, Suzanne Woolf suzworldw...@gmail.com wrote: Ed, First-- apologies for the misunderstanding. On Jul 1, 2015, at 9:53 AM, Edward Lewis edward.le...@icann.org wrote: Trying to be more clear, I have in the past imagined that today someone is inventing a new communications technology, in 6 months will need to cobble an identifier space and in 2 years the IETF-connected crowd detects significant deployment of this and needs to decide whether to register a TLD to avoid name collisions. I've been told that this wouldn't happen because the IETF will have rules - which I am skeptical would prevent the situation from happening. I don't think we have rules or even guidelines now that have any chance of preventing it. I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first. But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. Warren points at ALT-TLD Yup, we will not be able to prevent people from using an identifier space that looks like a DNS name not rooted in the DNS, but we *can* provide them with guidance and a safe place to do this sort of thing, namely under the .alt TLD. To underscore - I am not against the innovation. I am urging that the processes put in place are future proof by being reactionary - reacting to the new names, not trying to fend off the situation. I.e., in agreement with the words below trying to apply RFC 6761 and finding that it remains subjective. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? I believe so, but instead of simply raising the bar to get a special use name (which will simply result in people squatting more), I think we need to provide solid, usable advice and an option for people... +many to what Warren says. We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. --Richard W thanks, Suzanne On 7/1/15, 9:05, Suzanne Woolf suzworldw...@gmail.com wrote: (no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On 7/1/15, 14:26, Richard Barnes r...@ipv.sx wrote: We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. How does that help this: On 7/1/15, 1:47, st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. Having a alt-TLD is fine. But what if names are proposed, experimented and deployed outside the sphere of influence of the IETF and/or working group? Writing this as someone who is unfamiliar with other proposed P2P-Names efforts and whether they want to engage with standards bodies before deploying. I've gotten the impression that members of those efforts dislike standards processes - I may be wrong but that's the impression I've gotten from the discussion on this list. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
Thanks Olafur. The Workign Group should discuss this as it was originally planned to go into a Working Group Last Call. It can still be taken in this direction. tim On 7/1/15 8:52 AM, Olafur Gudmundsson wrote: This version is a final version from the editors. We explicitly punt on explaining how to overcome the situation when a ´proxy/forwarder’ “randomly” sends queries to Resolvers with different capabilities. Olafur On Jul 1, 2015, at 8:49 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Roadblock Avoidance Authors : Wes Hardaker Olafur Gudmundsson Suresh Krishnaswamy Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt Pages : 16 Date: 2015-07-01 Abstract: This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approache to detect and overcome network issues that a DNSSEC software/system may face. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ 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
[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Roadblock Avoidance Authors : Wes Hardaker Olafur Gudmundsson Suresh Krishnaswamy Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt Pages : 16 Date: 2015-07-01 Abstract: This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approache to detect and overcome network issues that a DNSSEC software/system may face. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?
Dan, This looks as though it will be a really interesting exercise. I will be there in spirit (and in corporeal form Sunday afternoon). -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A From: Dan York y...@isoc.orgmailto:y...@isoc.org Date: Wednesday, July 1, 2015 at 7:43 AM To: dnsop dnsop@ietf.orgmailto:dnsop@ietf.org Subject: [DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy? DNSOP participants, Will you be in Prague on the weekend before IETF 93? (Or could you get there?) A number of us will be involved with the hackathon happening on Saturday and Sunday: https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon Our intent is to work on some tools/services related to DANE, DNSSEC and/or DNS privacy - either adding support to existing tools or projects, or developing something new that is useful in some way (and is not a duplicate of something else). We don't have specific projects lined up yet (we need to meet and decide what we're going to do)... but any suggestions are certainly welcome. If you'd like to join for either one or both days, the link to sign up is on that hackathon page. Here's what we wrote as an abstract: * DANE / DNS Privacy / DNSSEC * Contribute to access of end-systems to new developments in DNS * Protocols: DANE support for webmail, DNS-over-TLS (application uses), DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for EDNS client-subnet, getdns language bindings, etc. * Tools: portable tool for creating and adding DANE RR’s to zones, changes to existing tools to support new crypto algorithms, etc. * Measurement: New tools or sites for measuring DNSSEC or DANE deployment * Available open source libraries: https://github.com/verisign/smaug, https://github.com/getdnsapi * Available environment, support, and diagnostic tools: https://dnssec-tools.org, https://www.opendnssec.org * Champions * Dan York, Internet Society y...@isoc.orgmailto:y...@isoc.org * Allison Mankin, Verisign Labs aman...@verisign.commailto:aman...@verisign.com * Willem Toorop, NLnet Labs * Sara Dickinson, Sinodun * Others, TBA Anyone is welcome to join with us. The current list of participants is here: https://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login=%0Ahttps://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login= (you can see that some people have listed that they will join in for DNS-related topics...) See (some of) you in Prague, Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.orgmailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
Ed, First-- apologies for the misunderstanding. On Jul 1, 2015, at 9:53 AM, Edward Lewis edward.le...@icann.org wrote: Trying to be more clear, I have in the past imagined that today someone is inventing a new communications technology, in 6 months will need to cobble an identifier space and in 2 years the IETF-connected crowd detects significant deployment of this and needs to decide whether to register a TLD to avoid name collisions. I've been told that this wouldn't happen because the IETF will have rules - which I am skeptical would prevent the situation from happening. I don't think we have rules or even guidelines now that have any chance of preventing it. I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first. But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. To underscore - I am not against the innovation. I am urging that the processes put in place are future proof by being reactionary - reacting to the new names, not trying to fend off the situation. I.e., in agreement with the words below trying to apply RFC 6761 and finding that it remains subjective. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? thanks, Suzanne On 7/1/15, 9:05, Suzanne Woolf suzworldw...@gmail.com wrote: (no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP can comment on is how the DNS reacts to names, whether in protocol or operational convention, once they are known before they achieve some degree of widespread adoption. To what extent is an effort made (by whomever) to detect these budding namespaces, is this proactive? ___ 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-dnssec-roadblock-avoidance-02.txt
This version is a final version from the editors. We explicitly punt on explaining how to overcome the situation when a ´proxy/forwarder’ “randomly” sends queries to Resolvers with different capabilities. Olafur On Jul 1, 2015, at 8:49 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Roadblock Avoidance Authors : Wes Hardaker Olafur Gudmundsson Suresh Krishnaswamy Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt Pages : 16 Date: 2015-07-01 Abstract: This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approache to detect and overcome network issues that a DNSSEC software/system may face. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
(no hats, for the moment) Ed, It seems to me that this is exactly the issue: we've already had multiple drafts requesting new entries in the special use names registry, and expect more. Your note sounds as if you're fairly sanguine about a stream of unpredictable requests; however, based on what we've seen so far, I admit I'm not. I'm still re-immersing in DNSOP after being entirely absorbed in other work the last couple of weeks, but I want to support us continuing this discussion, because it seems to me that the point Andrew started the thread to make is valid: we don't have a coherent view of how the relevant namespaces (based on DNS protocol, compatible with DNS protocol but intended for different protocol use, or otherwise) interact. The painful immediate consequence is that we're trying to apply RFC 6761 and finding that it remains subjective to do so, with an element of beauty contest in the deliberations that means outcomes are unpredictable. There's no meaningful guidance we can give developers on what names it's safe for them to use in new protocols, or even for specific uses in-protocol, and as Andrew and others have pointed out, there may even be ambiguity about what our own registries mean in protocol or operational terms. Longer term, this lack of clarity has implications for both architecture and policy for the DNS, including our ability to support innovation and to coordinate with other groups in the IETF and beyond. best, Suzanne On Jul 1, 2015, at 8:26 AM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 1:47, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. I'd been told that onion. was a one-time thing, that in the future conflicts wouldn't happen. What I read in the quoted message is that onion.'s request isn't a one-time thing but a sign of things to come. I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names - instead of building a separate application base. I expect innovation to be free-form and thus a stream of unpredictable requests to reserve names for special purposes, including DNS-like names. What DNSOP can comment on is how the DNS reacts to names, whether in protocol or operational convention, once they are known before they achieve some degree of widespread adoption. To what extent is an effort made (by whomever) to detect these budding namespaces, is this proactive? ___ 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-dnssec-roadblock-avoidance-02.txt
On Jul 1, 2015, at 9:31 AM, Tim Wicinski tjw.i...@gmail.com wrote: Thanks Olafur. The Workign Group should discuss this as it was originally planned to go into a Working Group Last Call. It can still be taken in this direction. tim Tim We request a WGLC on the document Olafur On 7/1/15 8:52 AM, Olafur Gudmundsson wrote: This version is a final version from the editors. We explicitly punt on explaining how to overcome the situation when a ´proxy/forwarder’ “randomly” sends queries to Resolvers with different capabilities. Olafur On Jul 1, 2015, at 8:49 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNSSEC Roadblock Avoidance Authors : Wes Hardaker Olafur Gudmundsson Suresh Krishnaswamy Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt Pages : 16 Date: 2015-07-01 Abstract: This document describes problems that a DNSSEC aware resolver/ application might run into within a non-compliant infrastructure. It outline potential detection and mitigation techniques. The scope of the document is to create a shared approache to detect and overcome network issues that a DNSSEC software/system may face. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?
DNSOP participants, Will you be in Prague on the weekend before IETF 93? (Or could you get there?) A number of us will be involved with the hackathon happening on Saturday and Sunday: https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon Our intent is to work on some tools/services related to DANE, DNSSEC and/or DNS privacy - either adding support to existing tools or projects, or developing something new that is useful in some way (and is not a duplicate of something else). We don't have specific projects lined up yet (we need to meet and decide what we're going to do)... but any suggestions are certainly welcome. If you'd like to join for either one or both days, the link to sign up is on that hackathon page. Here's what we wrote as an abstract: * DANE / DNS Privacy / DNSSEC * Contribute to access of end-systems to new developments in DNS * Protocols: DANE support for webmail, DNS-over-TLS (application uses), DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for EDNS client-subnet, getdns language bindings, etc. * Tools: portable tool for creating and adding DANE RR’s to zones, changes to existing tools to support new crypto algorithms, etc. * Measurement: New tools or sites for measuring DNSSEC or DANE deployment * Available open source libraries: https://github.com/verisign/smaug, https://github.com/getdnsapi * Available environment, support, and diagnostic tools: https://dnssec-tools.org, https://www.opendnssec.org * Champions * Dan York, Internet Society y...@isoc.orgmailto:y...@isoc.org * Allison Mankin, Verisign Labs aman...@verisign.commailto:aman...@verisign.com * Willem Toorop, NLnet Labs * Sara Dickinson, Sinodun * Others, TBA Anyone is welcome to join with us. The current list of participants is here: https://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login=%0Ahttps://www.ietf.org/registration/ietf93/hackathonattendance.py?sortkey=3login= (you can see that some people have listed that they will join in for DNS-related topics...) See (some of) you in Prague, Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.orgmailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On 7/1/15, 10:08, Suzanne Woolf suzworldw...@gmail.com wrote: But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own. (struct IETF *) We can always provide guidance. But processes cannot rely on applicants (tacit or not) to either be aware of the guidance or, more significantly, to heed it. Prepare for the best, expect the worst. (Or that conservative, liberal bon mot.) I certainly don't think it is right to *expect* that everyone will heed the guidance, so we need to build the process as if we didn't give the guidance in the first place. This supports the initial suggestion that we need to get serious about a 6761bis, am I correct? Yes. I'm not satisfied with the process in RFC 6761. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-cookies-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Domain Name System (DNS) Cookies Authors : Donald E. Eastlake Mark Andrews Filename: draft-ietf-dnsop-cookies-03.txt Pages : 30 Date: 2015-07-01 Abstract: DNS cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification / forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and anycast and can be incrementally deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-cookies-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On 1 Jul 2015, at 10:08, Suzanne Woolf wrote: First-- apologies for the misunderstanding. It seems appropriate for someone at this point to make a joke about onion leaving a bad taste in the mouth. But not me. I'm not that guy. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
On Wed, Jul 1, 2015 at 2:54 PM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 14:26, Richard Barnes r...@ipv.sx wrote: We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. How does that help this: On 7/1/15, 1:47, st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. Having a alt-TLD is fine. But what if names are proposed, experimented and deployed outside the sphere of influence of the IETF and/or working group? Writing this as someone who is unfamiliar with other proposed P2P-Names efforts and whether they want to engage with standards bodies before deploying. I've gotten the impression that members of those efforts dislike standards processes - I may be wrong but that's the impression I've gotten from the discussion on this list. The thing that got .onion to the IETF is that they needed to be official. (So that they could get certificates for .onion names.) Until they get an RFC 6761 registration, they're in a grey zone of being neither officially DNS names nor officially not DNS names. ISTM that the benefit of .alt is that it creates a clearly-not-normal-DNS zone. We would have to check with the CAs, but I think that that would do a lot to prevent issues like what .onion ran into. My hope would be that that benefit would make it appealing enough for at least some of these other pseudo-TLDs to tolerate the switching cost. --Richard ___ 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] More after onion? was Re: Some distinctions and a request
On Wed, Jul 1, 2015 at 3:05 PM, Richard Barnes r...@ipv.sx wrote: On Wed, Jul 1, 2015 at 2:54 PM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 14:26, Richard Barnes r...@ipv.sx wrote: We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. How does that help this: On 7/1/15, 1:47, st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. Having a alt-TLD is fine. But what if names are proposed, experimented and deployed outside the sphere of influence of the IETF and/or working group? Writing this as someone who is unfamiliar with other proposed P2P-Names efforts and whether they want to engage with standards bodies before deploying. I've gotten the impression that members of those efforts dislike standards processes - I may be wrong but that's the impression I've gotten from the discussion on this list. The thing that got .onion to the IETF is that they needed to be official. (So that they could get certificates for .onion names.) Until they get an RFC 6761 registration, they're in a grey zone of being neither officially DNS names nor officially not DNS names. ISTM that the benefit of .alt is that it creates a clearly-not-normal-DNS zone. We would have to check with the CAs, but I think that that would do a lot to prevent issues like what .onion ran into. My hope would be that that benefit would make it appealing enough for at least some of these other pseudo-TLDs to tolerate the switching cost. It also provides the ability for the IETF to push back more easily on some applications. Warning: The following is how this plays out in my mind. Many things in here are a little odd, but, hey, it's my imagination, not yours... Dramatis personae: Applicant: A young, eager developer. IETF (personification): Played by someone who looks like a cross between Spencer Dawkins and Scott Bradner. For some reason speaks with a strong Scottish accent... Without .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label. Anyway, a namespace made up of cartoon character names is silly... Applicant: But this meets all of the 6761 requirements, and I've got dozens of people using this. Anyway, I didn't really have an alternative, did I? How is anyone supposed to innovate in the namespace?! IETF: Well, erm you should have... e... um... ideally you would... err... Yeah, OK, we'll make .foo be a Special Use Name, but don't do it again, OK?! (Applicant skips off stage left, IETF plods off stage right, looking dejected) With .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label; we have a defined process and location for this sort of thing, it's called .alt IETF waves sheaf of papers Anyway, cartoon characters as a basis for a namespace? Really? Applicant: But I didn't know about .alt... and I've got dozens of users, dozens I tell you...shakes fist IETF: Sorry, ignorantia legis neminem excusat. Applicant: Fine (Applicant stomps off stage left in a bit of a huff, IETF looks remarkably smug, then exits stage right to further examine navel) [ Unfortunately the IETF ends up looking like a bit of an ass here, but redeems itself later by doing something helpful for the community, or, at least, entertaining... Hey, I did warn you that things in my brain are often a little, um, surreal... ] The IETF can still add things to the RFC6761 / RFC6761bis registries, but at least has: A: provided an alternative for people who /want/ to do the right thing and B: more of a leg to stand on if we need to push back on nuisance applications in the future. W --Richard ___ 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 -- 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
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
+many to what Warren says. We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. I agree. On the other hand, since we are not the tsars of the Internet, it is fairly likely that no matter what we do, someone will start using .ramp (a stronger version of .onion) rather than .ramp.alt and it will become widely enough used that it makes technical sense to keep it out of the DNS, like .onion and .home. That would not be a disaster. I don't even see it as a problem, so long as we have a process to weigh the pros and cons and decide whether to add it to the list of domain names that are excluded from the DNS. (It may cause gnashing of teeth at ICANN as it screws up someone's business plan, which is definitely not our problem.) I suppose that if we update RFC 6761 it would be polite to send a note to ICANN reminding them that anyone who wants to add a new TLD to the DNS should consider as one of the risks that it collides with a name that is excluded for technical reasons, but I see no reason to go farther than that. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
... and this was only intended to go to Richard and Ed, not waste the entire WGs time with my bizarre imaginings... W On Wed, Jul 1, 2015 at 4:59 PM, Warren Kumari war...@kumari.net wrote: On Wed, Jul 1, 2015 at 3:05 PM, Richard Barnes r...@ipv.sx wrote: On Wed, Jul 1, 2015 at 2:54 PM, Edward Lewis edward.le...@icann.org wrote: On 7/1/15, 14:26, Richard Barnes r...@ipv.sx wrote: We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. How does that help this: On 7/1/15, 1:47, st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. Having a alt-TLD is fine. But what if names are proposed, experimented and deployed outside the sphere of influence of the IETF and/or working group? Writing this as someone who is unfamiliar with other proposed P2P-Names efforts and whether they want to engage with standards bodies before deploying. I've gotten the impression that members of those efforts dislike standards processes - I may be wrong but that's the impression I've gotten from the discussion on this list. The thing that got .onion to the IETF is that they needed to be official. (So that they could get certificates for .onion names.) Until they get an RFC 6761 registration, they're in a grey zone of being neither officially DNS names nor officially not DNS names. ISTM that the benefit of .alt is that it creates a clearly-not-normal-DNS zone. We would have to check with the CAs, but I think that that would do a lot to prevent issues like what .onion ran into. My hope would be that that benefit would make it appealing enough for at least some of these other pseudo-TLDs to tolerate the switching cost. It also provides the ability for the IETF to push back more easily on some applications. Warning: The following is how this plays out in my mind. Many things in here are a little odd, but, hey, it's my imagination, not yours... Dramatis personae: Applicant: A young, eager developer. IETF (personification): Played by someone who looks like a cross between Spencer Dawkins and Scott Bradner. For some reason speaks with a strong Scottish accent... Without .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label. Anyway, a namespace made up of cartoon character names is silly... Applicant: But this meets all of the 6761 requirements, and I've got dozens of people using this. Anyway, I didn't really have an alternative, did I? How is anyone supposed to innovate in the namespace?! IETF: Well, erm you should have... e... um... ideally you would... err... Yeah, OK, we'll make .foo be a Special Use Name, but don't do it again, OK?! (Applicant skips off stage left, IETF plods off stage right, looking dejected) With .alt: (Applicant enters stage left) Applicant: I'd like .foo added to the SUN registry please. I've developed a resolution service that maps from names of cartoon characters to IP addresses, and is use by many many people. It meets all the RFC6761 requirements IETF: You did a bad thing. You should not have simply squatted on a label; we have a defined process and location for this sort of thing, it's called .alt IETF waves sheaf of papers Anyway, cartoon characters as a basis for a namespace? Really? Applicant: But I didn't know about .alt... and I've got dozens of users, dozens I tell you...shakes fist IETF: Sorry, ignorantia legis neminem excusat. Applicant: Fine (Applicant stomps off stage left in a bit of a huff, IETF looks remarkably smug, then exits stage right to further examine navel) [ Unfortunately the IETF ends up looking like a bit of an ass here, but redeems itself later by doing something helpful for the community, or, at least, entertaining... Hey, I did warn you that things in my brain are often a little, um, surreal... ] The IETF can still add things to the RFC6761 / RFC6761bis registries, but at least has: A: provided an alternative for people who /want/ to do the right thing and B: more of a leg to stand on if we need to push back on nuisance applications in the future. W --Richard ___ 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Edward Lewis wrote: On 7/1/15, 14:26, Richard Barnes r...@ipv.sx wrote: We do our best work when we do engineering, not rule-making. Let's engineer a solution here that's more appealing than squatting. For my money, alt-TLD looks about right. How does that help this: On 7/1/15, 1:47, st...@i2pmail.org wrote: .onion and .i2p (and to my knowledge, the other proposed P2P-Names TLDs too) have to conform to DNS rules in order to be usable in legacy applications that expect domain names. Having a alt-TLD is fine. But what if names are proposed, experimented and deployed outside the sphere of influence of the IETF and/or working group? Writing this as someone who is unfamiliar with other proposed P2P-Names efforts and whether they want to engage with standards bodies before deploying. I admit to being highly surprised that you are unfamiliar with the P2P-Names draft[0], given that it pre-dates the later .onion-only draft. To save you trawling through the archives, the P2P-Names draft was proposed to bring the TLDs contained within onto the SUN registry under RFC 6761. However, neither I2P nor Tor (I cannot speak for the others) engaged with any standards body before deploying, because (IMHO, I was not around at the time) a) there was no clear indication that the floodgates would (or could) be opened for TLDs, and therefore no obvious reason for concern, and b) RFC 6761 did not exist at the time. I2P deployed .i2p in 2003[1], and Tor deployed .onion in 2004[2]; RFC 6761 was published in 2013. I've gotten the impression that members of those efforts dislike standards processes - I may be wrong but that's the impression I've gotten from the discussion on this list. I certainly don't dislike standards processes. What I _do_ dislike is inconsistency and poor documentation/education. If DNSOP / IETF wants to ensure that future applications root their name spaces in .alt or wherever else instead of choosing a .TLD to add to the SUN registry, then developers _need to know about it_. I personally agree with Richard that .alt is far more appealing than the struggle to get a .TLD added to the SUN registry, but the longer it took me to discover .alt, the harder it would be to justify switching. (It's for this reason that .i2p is as unlikely as .onion to be moved into .alt, with well over a decade of use, and .alt not even in existence yet.) Having it stated in an RFC is definitely better than the status quo, but IMHO it would be much better to have an FAQ page that clearly outlines the IETF's / working group's position, itself backed by references to RFCs. Then use SEO to get it near the top of any related search query. It wouldn't take much work, and the IETF's / working group's sphere of influence would be far wider as a result. Developers love bullet points :P str4d [0] https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam es/ [1] https://geti2p.net/en/meetings/059 [2] https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#cite_ref-or-lo cating_85-0 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVlGuMAAoJEBO17ljAn7PgOesQAKjnyUJAceWnEgPTKWzb/LXU LkcJ1cZPQsRAilfM1h3GNJ6tg7ZYDZcr16nwNzfbSfYhI/LQpLOhGm1VxM7vVjB0 01hBaOZnJoehlTmSO/6H+lPfwE2GnMrtM3LMbytPIFSYKtnTqU6pgZcA2StvPr0P eoXpNofJ8hMX31FB117D7glzOycuUqm3GN/aurKj13B1uXjLGQxFAYwQxyfc1JB5 VYD2q7WtacJSJPGC7orgBu+LI6GYg9Cjb7+Bj6BLjT+NZ/6c46kvZ2KOnoFI/7Hg jgtM9Z1FmWGEnbKwsb3LdctOWU1FtWrSeepp2f4Sg3NVJM0FdYTE5N2zyKWP0nPc EMosnJRDOLsCL324sbj5HIZ1vL46OO+HWZWur3gRGgDBUmqjIBfONfu3qnXmL7UG 3JRtdM83FLht2xI+iYdbY059LQsU9t3LR5BUJnv9IVuz6ELHi1i5pEF1bTY2AvGl taZax7lhB+jhQgcfITIzx3rlxOMv8wdsSq0L/ynJqm9afqGTU/G5S9k1vJaXunnU IULAvouQ4iERufzrUwKHh94Vd/HhbrOF/Oc5z7ObtTPSjBvmLPIRoxYl2c8xV7WR 73+K3L6rxifqP1ITMo8MiFO4+sr70c7oyqS+gRSdWLRoh2xkNTNIAXoahyegSk8F WdHJBvBnvbByyyatoHu5 =/8p1 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] More after onion? was Re: Some distinctions and a request
Hi Ed, On Wed, Jul 01, 2015 at 12:26:43PM +, Edward Lewis wrote: I'm sympathetic to the use the path of least resistance - e.g., use names that syntactically are DNS names I note that the Subject: line of your note still contains a vestigial reference to the thread I started recently on this, and your message nevertheless returns to collapsing domain names and DNS names. I don't know whether I've simply failed to explain the distinction I'm trying to make, or whether you reject the premise. Could you please be clear about which it is? To me, the _point_ of onion. is that it is not a DNS name. You're right that it has the same syntax -- because it is a domain name, but not (intended to be) a DNS name. The registration of the name in the special use registry would achieve that end. You might object that this distinction is extremely hard, because there's nothing about the label itself to signal this namespace shift, and unaware clients will therefore automatically just treat such names as DNS names, not special-use domain names. I happen to agree with that, but we cannot hold back this tide: it was let loose once local. became an in-band protocol switch, without any registration, in Apple's widely-deployed Bonjour service. We might wish that people hadn't abused the namespace to turn it into protocol switches as well as everything else, but the history of SRV through Bonjour shows that this technique is popular and unlikely to go away. Commanding the tide to stay back when you are neck deep in water is not likely to work. Therefore, I claim, we need to make some clear distinctions and understand what has actually happened, and then adjust to the new reality. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-cookies-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Domain Name System (DNS) Cookies Authors : Donald E. Eastlake Mark Andrews Filename: draft-ietf-dnsop-cookies-04.txt Pages : 30 Date: 2015-07-01 Abstract: DNS cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification / forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT, and anycast and can be incrementally deployed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key
On Tue, 30 Jun 2015, Warren Kumari wrote: I have been planning to write a draft to address 1 by having validators send the DS of known TA's in an edns0 option code. This info, could then be logged by the authoritative nameservers. Inserting it in edns0 implies (I think) that all of the queries will contain this, which seems like a fairly big query size / efficiency hit. I guess you could just do it every N queries, or M time, or something. Very similar idea though... Why? You would only add it to the question for DNSKEY of the root. Maybe only after you determined a validation failure, so you clearly have the wrong trust anchor. It seems in general, having some special record signed by only the new key seems a nicer solution, as it allows for large network monitors (eg atlas) to use unmodified dns servers. But it will require some kind of legal/contractual change :( Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
