Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On Sat, Jul 18, 2015 at 11:27:21PM -0400, John R Levine wrote: But once again, if we start inventing hoops for people to jump through, they won't. That's counterproductive since we have no control over what they're doing, so we'd like them to voluntarily tell us. Yes. The point of the alt space is that people can do whatever they want there, not that they can do what they want if they sign up for such doing. We have no idea whether this will work, but it's worth a try. I am strongly opposed to adding an IANA registry for alt. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Hugo, et al, I think the experience is exactly the opposite, i.e. these names will *always* show up in the DNS. As a consequence, I would argue that names being used for any of these purposes should not be delegated into the DNS root unless it’s for the same purpose. Thus, if the village of Elba in the state of New York, USA, which calls itself the Onion Capital of the World applied to ICANN for .onion in some future round of gTLD applications, I would hope ICANN would turn down the application on the basis that the name is already in use. I should note that not all of my colleagues agree with me. When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC) we noted that .belkin was one of the undelegated names that shows up quite frequently at the root. If .belkin were delegated in the root, it would instantly change the responses those queries are currently receiving, thus raising some questions about security and/or stability for those end systems that have been generating bogus .belkin queries to root for many years. I haven’t looked to see how often .onion and .alt show up at the root. Others on this list can or already have done so. Steve On Jul 19, 2015, at 3:26 AM, Hugo Maxwell Connery h...@env.dtu.dk wrote: Hi, My reflections on this interesting discussion: Software using names under *.alt (or whatever it will be) do not use DNS, by definition. Thus, there can never be a DNS name collision. It will be up to the alternate name resolution software, and its users, to deal with the name collision problem, until IETF decides to take on name management for this/these non-DNS name resolution systems. So, we dont have to solve this problem. I dont believe that a registry is required at all. If we do offer one, that registry should be for dual entries (name, name resolution mechanism) as (sex.alt, tor hidden service) and (sex.alt, GNUnet) are different things using different mechanisms, but the same label. Regards, Hugo ___ 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] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On 07/19/2015 05:27 AM, John R Levine wrote: By this logic, using a FCFS 'registry' model implies at least enough information (if not a requirement) for some of tracking the registrant to confirm continued use, transfer, release or abandonment at the very least, no? To the extent that's practical, sure. There are plenty of existing IANA entries that have little more than an e-mail address to contact for more information. But once again, if we start inventing hoops for people to jump through, they won't. That's counterproductive since we have no control over what they're doing, so we'd like them to voluntarily tell us. And you want to be careful about what you require. Some P2P overlay network developers try hard to not reveal their identity. Not to mention, developers may change. Who is in charge of BitCoin or NameCoin? By what authority? Let me know if you find out ;-). (Hint: you cannot, nobody is.) E-mail addresses also don't work well: mine has changed over the years. I2P lost control over its original DNS domain for many years, breaking e-mail and domain name references to the project. But, it was always possible to find it for those looking... So what's practically achievable is likely way less than what would be desireable. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Hugo, et al, I think the experience is exactly the opposite, i.e. these names will *always* show up in the DNS. As a consequence, I would argue that names being used for any of these purposes should not be delegated into the DNS root unless it’s for the same purpose. Thus, if the village of Elba in the state of New York, USA, which calls itself the Onion Capital of the World applied to ICANN for .onion in some future round of gTLD applications, I would hope ICANN would turn down the application on the basis that the name is already in use. I should note that not all of my colleagues agree with me. When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC) we noted that .belkin was one of the undelegated names that shows up quite frequently at the root. If .belkin were delegated in the root, it would instantly change the responses those queries are currently receiving, thus raising some questions about security and/or stability for those end systems that have been generating bogus .belkin queries to root for many years. I haven’t looked to see how often .onion and .alt show up at the root. Others on this list can or already have done so. Steve Crocker (Founding chair of ICANN’s SSAC; currently chair of the ICANN board, speaking as an individual not officially on behalf of the ICANN board) On Jul 19, 2015, at 3:26 AM, Hugo Maxwell Connery h...@env.dtu.dk wrote: Hi, My reflections on this interesting discussion: Software using names under *.alt (or whatever it will be) do not use DNS, by definition. Thus, there can never be a DNS name collision. It will be up to the alternate name resolution software, and its users, to deal with the name collision problem, until IETF decides to take on name management for this/these non-DNS name resolution systems. So, we dont have to solve this problem. I dont believe that a registry is required at all. If we do offer one, that registry should be for dual entries (name, name resolution mechanism) as (sex.alt, tor hidden service) and (sex.alt, GNUnet) are different things using different mechanisms, but the same label. Regards, Hugo ___ 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] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt
On Mon, Jul 06, 2015 at 03:48:13PM -0400, Warren Kumari war...@kumari.net wrote a message of 68 lines which said: A number of people approached me at DNS-OARC and the RIPE DNS track in Amsterdam asking what became of this draft, and could we please update it. It's not on the agenda on monday, isn't it? Wes and I finally had some time to work on it in Buenos Aires, after the ICANN meeting (actually, Wes did the work, I just mumbled and brought him coffee...) I've re-read the discussion in January about version -00 and apparently the questions that come to my mind are not shared by anyone so here they are: * the draft gives the impression that it authorizes a new behaviour. But auth. servers have been sending extra data (IP address of a MX target, for instance) for years. * the draft says these extra data MUST (RFC2119-MUST) be validated with DNSSEC. Does it mean that the current behaviour of sending extra data for unsigned zones is now illegal? * [followup off the previous question] should we instead say that extra data should be sent (and should be accepted by clients) if and only if (DNSSEC-validated _or_ in-bailiwick)? The current behaviors of resolvers (accept extra data if in-bailiwick) does not seem to be mentioned. * the draft says an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache. This is very dangerous because people may read it we now have a sure way to control what ends in the resolver's cache which is clearly not the case (the resolver may refuse some of the extra data, the TTL of the extra data may mae it expire before the main data, etc). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt
On 7/19/15 10:47 AM, Stephane Bortzmeyer wrote: On Mon, Jul 06, 2015 at 03:48:13PM -0400, Warren Kumari war...@kumari.net wrote a message of 68 lines which said: A number of people approached me at DNS-OARC and the RIPE DNS track in Amsterdam asking what became of this draft, and could we please update it. It's not on the agenda on monday, isn't it? Warren has 10 minutes on the agenda on trust management, but he may choose to alter his talk. tim Wes and I finally had some time to work on it in Buenos Aires, after the ICANN meeting (actually, Wes did the work, I just mumbled and brought him coffee...) I've re-read the discussion in January about version -00 and apparently the questions that come to my mind are not shared by anyone so here they are: * the draft gives the impression that it authorizes a new behaviour. But auth. servers have been sending extra data (IP address of a MX target, for instance) for years. * the draft says these extra data MUST (RFC2119-MUST) be validated with DNSSEC. Does it mean that the current behaviour of sending extra data for unsigned zones is now illegal? * [followup off the previous question] should we instead say that extra data should be sent (and should be accepted by clients) if and only if (DNSSEC-validated _or_ in-bailiwick)? The current behaviors of resolvers (accept extra data if in-bailiwick) does not seem to be mentioned. * the draft says an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache. This is very dangerous because people may read it we now have a sure way to control what ends in the resolver's cache which is clearly not the case (the resolver may refuse some of the extra data, the TTL of the extra data may mae it expire before the main data, etc). ___ 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] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On 19 Jul 2015, at 10:02, Steve Crocker wrote: When I was chair of ICANN’s Security and Stability Advisory Committee (SSAC) we noted that .belkin was one of the undelegated names that shows up quite frequently at the root. If .belkin were delegated in the root, it would instantly change the responses those queries are currently receiving, thus raising some questions about security and/or stability for those end systems that have been generating bogus .belkin queries to root for many years. Later SSAC has continued to look at various namespace collision issues and have repeated the comments that various leakages is a. something that will happen (as Steve said), and b. because of the leakage it is important names are only used within the context they are intended to be used (so that the number of false positives is minimized). If more information is sought for, let me or any SSAC member know, or have a look yourself at https://www.icann.org/groups/ssac/documents. Patrik Fältström Current SSAC Chair ;-) signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Paul, On Jul 19, 2015, at 6:01 AM, Paul Vixie p...@redbarn.org wrote: there are no hoops here. people will register if they want to, and people will check the registry if they want to. For the people who want to register, an exclusive registry explicitly creates a discussion for everyone but the first registrant, i.e.: With a non-exclusive registry: Them: Hey IANA, we're using .PAUL and here's the docs describing who we are and how. IANA: OK. We'll add your information to the others already registered for that label. With an exclusive registry: Them: Hey IANA, we're using .PAUL and here's the docs describing who we are and how. IANA: Um, sorry. Someone else is already using that label. Them: But we really like .PAUL and we have deployed a zillion instances that make use of .PAUL IANA: That's fine, but you're potentially creating an interoperability problem. Them: So tell the other guys to stop, since we've been using .PAUL since the early 1700s. etc. This smells like a hoop to me. so: offering someone a chance to register that a conflict exists does not serve the purpose of advancing interoperability. It doesn't address the interoperability of non-interoperable domain name overlays. It does advance interoperability in the sense of improving the state of knowledge that the non-interoperable domain name overlays exist, how they operate, who runs them, etc. It seems to me that by making the registry exclusive, you're trying to put the IESG/IETF/IANA in the role of gatekeeper of the non-interoperable domain name overlays. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
I think this is a useful and interesting discussion. but it's anchored in the .alt proposal which we should separate from the onion tld last call I hope. Thanks joel On 7/19/15 6:55 AM, John R Levine wrote: so: offering someone a chance to register that a conflict exists does not serve the purpose of advancing interoperability. that is, the information ONION.ALT exists, see http://whatever; is useful, whereas the information ONION.ALT exists, see http://someplace and/or http://someplace_else; is not useful. this, to me, is what FCFS means. Really, I get that. But here's the two options: A) registry says ONION.ALT exists, see http://someplace and/or http://someplace_else;, you say hm, two different packages, I better look at both of them to see which one is installed on my computer. B) registry says ONION.ALT exists, see http://someplace;, you look at it and scratch your head when you realize it's not what's on your computer so you go do a Google search and eventually find http://someplace_else. There is no C), since we don't control what software people write. I don't understand why B) would be better for anyone. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt
On Sat, 18 Jul 2015 10:27:41 -0700, Paul Vixie wrote: John Heidemann wrote: ... I think one has to be careful comparing TCP and UDP attacks here. Yes, this is a DoS attack. The question is not can TCP be used to attack, but is it WORSE than UDP? Or how is it better and worse? in this solution space, possible outcomes are better, worse, no change, not better, and not worse. i think shane is arguing for never better and sometimes worse here. Correct. And I'm suggesting that (1) there's a misstep in that argument. He equates full-size TCP packets with short UDP packets to reach his sometimes worse claim. And I'm also suggesting (2) TCP allows a path to MUCH better against DoS. You say 7 packets vs. 40 packets. When under DoS, is DNS per-packet constrained or bitrate-constrained? With modern routers my understanding is it's usually bitrate not packet count that is the limit. Bitrate is about the same for UDP vs. TCP. ... if it were in our power (or especially in amazon's or google's or akamai's power) to cause the internet to be made up of mostly modern routers, then it would be so. alas, it is not in our power, and the internet will always have a long tail of routers we wish didn't exist any more. thus the aphorism, the least reliable and most expensive part of the internet is OPM -- other people's networks. for dns, we must design for the internet we will always have, not the internet we will always want. and on the internet we have, packets per second are a common bottleneck, such that an attacker knows they can reliably deny service with a small number of small packets, which do not saturate any link, but which do saturate the kinds of routers and firewalls people actually do still buy and use today. I agree, we need to prevent an attacker knows they can reliably deny service with a small number of small packets, which do not saturate any link. But that is not *Shane's scenario*. Shane's scenario was 7 FULL-LENGTH TCP packets vs. 40 SHORT UDP packets. That is what I meant by bitrate is about the same for UDP vs. TCP. Shane's attack is not a shrew-style attack on TCP---he IS saturating the link, just with aa few big packets instead of many short packets. The first point you were making is we cannot change the routers: if it were in our power (or especially in amazon's or google's or akamai's power) to cause the internet to be made up of mostly modern routers, then it would be so. alas, it is not in our power, and the ... or dns, we must design for the internet we will always have, not the internet we will always want. and on the internet we have, packets per second are a common bottleneck, ... Agreed, we cannot upgrade other people's routers. But, I'm sorry, if you're running DNS on an old router, you're trivially DoS-able today. Millions of insecure computers to tens of Mb/s uplinks. It only takes a couple to saturate a link, either in packets or bits. My second point was (2) TCP allows a path to MUCH better. Your reply elided that part of my post, which was: Liang Zhu did some testbed experiments of DNS under UDP and TCP attacks---we found that DNS/TCP can be quite a bit more robust to DoS than UDP when one takes basic defenses like the HTTP people do (that is: rate-limit queries per connection, connections per IP, and use SYN cookies). See Figure 4 and section V-B in http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf for graphs. (These do not include your specific attack, but do consider spoofing and non-spoofing.) Let me state the advantage more explicitly: With UDP and spoofed source addresses, each attacker gets to hit you with their full line rate, AND you have to service all the queries. This exhausts your incoming bitrate, packet rate, or CPU speed depending on how you're configured. With TCP, you get a whole bunch of defenses: - Spoofing is prevented with SYN cookies, so a spoofing attacker never gets to hit you with Shane's full length packets in the first place. The spoofed IPs are stopped at the SYN with NO state on the defender's server. SYNs are much faster to handle than full DNS queries. In our scenario, 1 or 2 UDP attackers could flood our small server at about 300k queries/s. But we could easily handle 250k SYNs/s with SYN cookies. (The kernel turns them around without any application involvement.) - No spoofing forces the attacker to reveal each zombie's identity. Now that attackers have to show their identity (no spoofed source addresses!), you can do MUCH EASIER rate limiting. Start by limiting concurrent connections per source IP. The attacker now must deploy 6000 zombies where 2 or 6 would do before. To prevent Shane's attack, one also has to rate limit queries per connection. We didn't consider this specific attack, but I think the defense follows. The numbers and graphs I quote above are in Figure 4 and section V-B in http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf if you want details about our
Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
Mark, Thanks for your explanation. My comments are inline... -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews If the victim node is behind NAT (servers are not behind NAT), and attacker is not in the same network, IMO, it cannot perform any amplification or DoS attack on the victim node. unless otherwise, the attacker is aware of the communication and ports used for the clients behind the NAT. Therefore, the use of this mechanism is not applicable in such situation. Therefore, I do not see any use case for nodes behind NAT. It can DoS the path to the NAT. All the attacker needs is the public address of the NAT. For the DoS stream to go through the NAT assuming it is a stateful NAT then yes the attacker needs more knowledge. So, you want such mechanism is implemented in NAT devices to protect all clients in that network, right? If not, the implementation of that in a single client behind the NAT, doesn't help all the clients inside that NAT network because the target is a public address of this device and other devices are not seen. This is , of course, according to your argument. Because if the attacker is using the public address of the NAT device then it is the NAT device who is the target of DoS. Then, if the mechanism wants to be applicable, then NAT device is the device which needs to implement this mechanism and not each client and add this option to any packet passes it that targets a recursive DNS server or store the state of server cookie. If the client has a global IP address, for example if it uses IPv6 that usually the IP address is global, then the attacker has a possibility to perform the DoS attack even though the client uses this method. because: - As far as I understood from the method, It is similar to enclosed figures (the algorithm is only arbitrary algorithm but this really does not matter). The problem is that still amplification and spoofing or any attacks explained in the draft is possible The reasons are as follows: 1- client doesn't know the random number used by the server to calculate the servers' cookie response. if it needs to know then it returns to the barrier of sharing this value between clients and servers The client sends queries only with client cookies initially. These are treated like any other unauthenticated query. They are subject to rate limiting of responses and sending back minimal responses (rcode=BADCOOKIE or TC=1). If the server doesn't keep the state, then based on the algorithms explained in the draft, the server cannot differentiate between different clients and each time it might generate a new server_cookie for each requests (I had it in my previous message on the figure attached to the message) because: [1] Server_cookie=Pseudo_function(client_cookie + server_secret) Therefore, even though, the client stores state about the server_cookie, each time for each query request, server will give it back a new cookie that clients cannot compare and calculate it and it is like a completely new query. Furthermore, if we assume that the algorithm is like the following, so that the server produces, everytime, the same cookie for the client and if the assumption is that the client knows the IP address of the server, then the attacker still has the possibility to spoof the source IP of DNS server because there is no actual server authentication and no one can proof that the message comes from the legitimate DNS server. [2] Server_cookie=Pseudo_function(client_cookie) So, in [2] the attacker once ask for a query from this DNS server, it can get to know how DNS server calculates the cookie and since it is not changeable over the time, the attacker can spoof the DNS server. In other word, training phase in not useful in both scenario and keeping state on client doesn't also help to mitigate the attack. 2- The server has no way to authenticate the client. so, it also accepts any arbitrary request from the attacker with forged IP address. Using cookie also doesn't help otherwise * the client uses the global IP address * the attacker could not sniff the first communication when the client sends its cookie * the server stores the cookie and its mapping to the IP address of the client (this doesn't make sense for NAT as there are more than one node behind a single Ip address) Well the server does not store any state. All state is stored by the client. The server uses a the IP address and the client cookie and the server secret to compute a server cookie. This it adds to the response then discards. Furthermore: 3- the server doesn't know the random number used by client to calculate client_cookie therefore if the server doesn't store this mapping (that in public resolvers it does not make sense) the resolver cannot authenticate the client and it also accepts cookies from the attacker Yes it can. It has all
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Hi, My reflections on this interesting discussion: Software using names under *.alt (or whatever it will be) do not use DNS, by definition. Thus, there can never be a DNS name collision. It will be up to the alternate name resolution software, and its users, to deal with the name collision problem, until IETF decides to take on name management for this/these non-DNS name resolution systems. So, we dont have to solve this problem. I dont believe that a registry is required at all. If we do offer one, that registry should be for dual entries (name, name resolution mechanism) as (sex.alt, tor hidden service) and (sex.alt, GNUnet) are different things using different mechanisms, but the same label. Regards, Hugo ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
* Stephane Bortzmeyer: On Wed, Jul 15, 2015 at 02:22:58PM -0700, Francisco Obispo fobi...@uniregistry.com wrote a message of 48 lines which said: Well, even worse, what happens if name-your-next-OS-vendor decides to create a new dns-like protocol that uses .foo, does that mean that we should automatically block it? No need to speculate about what happens. It already happened, the vendor was Apple and the result was the registration of .local (first use of RFC 6761). Wasn't this part of RFC 6761 specifically created to allow the reservation of .LOCAL, resolving the ICANN/IETF deadlock that had prevented this before? (In other words, the causal relationship is different, so it's not really an example of what could happen.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
In message 001501d0c1ec$52898050$f79c80f0$@rozanak.com, Hosnieh Rafiee writes: Mark, Thanks for your explanation. My comments are inline... -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mark Andrews If the victim node is behind NAT (servers are not behind NAT), and attacker is not in the same network, IMO, it cannot perform any amplification or DoS attack on the victim node. unless otherwise, the attacker is aware of the communication and ports used for the clients behind the NAT. Therefore, the use of this mechanism is not applicable in such situation. Therefore, I do not see any use case for nodes behind NAT. It can DoS the path to the NAT. All the attacker needs is the public address of the NAT. For the DoS stream to go through the NAT assuming it is a stateful NAT then yes the attacker needs more knowledge. So, you want such mechanism is implemented in NAT devices to protect all clients in that network, right? If not, the implementation of that in a single client behind the NAT, doesn't help all the clients inside that NAT network because the target is a public address of this device and other devices are not seen. This is , of course, according to your argument. It helps those clients behind the NAT that implement cookies. Because if the attacker is using the public address of the NAT device then it is the NAT device who is the target of DoS. Then, if the mechanism wants to be applicable, then NAT device is the device which needs to implement this mechanism and not each client and add this option to any packet passes it that targets a recursive DNS server or store the state of server cookie. Having middle boxes modify packets is a *bad* *idea*. If the client has a global IP address, for example if it uses IPv6 that usually the IP address is global, then the attacker has a possibility to perform the DoS attack even though the client uses this method. because: - As far as I understood from the method, It is similar to enclosed figures (the algorithm is only arbitrary algorithm but this really does not matter). The problem is that still amplification and spoofing or any attacks explained in the draft is possible The reasons are as follows: 1- client doesn't know the random number used by the server to calculate the servers' cookie response. if it needs to know then it returns to the barrier of sharing this value between clients and servers The client sends queries only with client cookies initially. These are treated like any other unauthenticated query. They are subject to rate limiting of responses and sending back minimal responses (rcode=BADCOOKIE or TC=1). If the server doesn't keep the state, then based on the algorithms explained in the draft, the server cannot differentiate between different clients and each time it might generate a new server_cookie for each requests (I had it in my previous message on the figure attached to the message) because: [1] Server_cookie=Pseudo_function(client_cookie + server_secret) Therefore, even though, the client stores state about the server_cookie, each time for each query request, server will give it back a new cookie that clients cannot compare and calculate it and it is like a completely new query. The client doesn't check the server cookie returned. It just stores it. The client checks the client cookie. The server checks the server cookie. Furthermore, if we assume that the algorithm is like the following, so that the server produces, everytime, the same cookie for the client and if the assumption is that the client knows the IP address of the server, then the attacker still has the possibility to spoof the source IP of DNS server because there is no actual server authentication and no one can proof that the message comes from the legitimate DNS server. [2] Server_cookie=Pseudo_function(client_cookie) Server_cookie=Pseudo_function(client cookie+client address+server secret) The client checks the client cookie *before* accepting the server cookie. So, in [2] the attacker once ask for a query from this DNS server, it can get to know how DNS server calculates the cookie and since it is not changeable over the time, the attacker can spoof the DNS server. No. The attacker doesn't see the reply traffic from the server. In other word, training phase in not useful in both scenario and keeping state on client doesn't also help to mitigate the attack. 2- The server has no way to authenticate the client. so, it also accepts any arbitrary request from the attacker with forged IP address. Using cookie also doesn't help otherwise * the client uses the global IP address * the attacker could not sniff the first communication when the client sends its cookie * the server stores the cookie and its mapping to the IP address of the client (this
Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
So, you want such mechanism is implemented in NAT devices to protect all clients in that network, right? If not, the implementation of that in a single client behind the NAT, doesn't help all the clients inside that NAT network because the target is a public address of this device and other devices are not seen. This is , of course, according to your argument. It helps those clients behind the NAT that implement cookies. When the clients are not seen, I just wonder how the attacker can target them?? NAT device doesn't know what to do with packets that coming from a xx machine that the source address is its own address without seeing any more information regarding ports, etc. so that it can redirect the requests to the target client. Either our definition from NAT device is different that is we are talking about two different device with two different functionality or there is a new generation of NAT devices that are so intelligent and know what to do when they receive undefined packets. Because if the attacker is using the public address of the NAT device then it is the NAT device who is the target of DoS. Then, if the mechanism wants to be applicable, then NAT device is the device which needs to implement this mechanism and not each client and add this option to any packet passes it that targets a recursive DNS server or store the state of server cookie. Having middle boxes modify packets is a *bad* *idea*. Might be, but this is also not applicable. The client doesn't check the server cookie returned. It just stores it. The client checks the client cookie. The server checks the server cookie. If the client does not check the server cookie in a initial step, then why don't you send anything to server so that the server needs also to do some processes which, of course, need processing time and this is vital for the server. Take it easy and Only keep the state in your client similar to the following simple example and do not bother server as based on the arguments and the explanation in the draft, the involvement of the server doesn't help neither in authenticating the server nor doing any prevention of attacks. In other word, the server only do some steps that is not necessarily help the client. (this conclusion is according to your own explanation such as : The server is free to use different algorithms to generate it's key. DNS COOKIE doesn't specify the exact algorithm to use. Simple Example that has the same impact as dnsop-cookies mechanism: Client A sends a query to DNS server A. Client A stores the state (e.g. query for www.example.com status: sentresponse: false) The DNS server responds this client with the query response. Client checks its state storage and found that the response value was false. So it accepts the value from the server since it was waiting for a response. Then remove this state from its state storage as it no longer needs to ask any query. Now, the bad guy wasn't aware of those communication but, with a miracle, found that what IP address is used by Client A so that he can target this client who is behind the NAT. So the bad guy sends a lot of query requests to the server with spoofed client IP address as a source address. DNS server sends query responds to the victim client (Client A). Victim client only check its state storage and found that it never request for any query. So, it silently discard all queries. Now about miracle part, I do not know how the attacker can obtain the IP address of the client without sniffing the communication or has a possibility to eavesdrop. If he can eavesdrop, then he also can know all the information exchanged between client and the server. Therefore, I am still confused that how this scenario, even the simplest one in my example, works behind the NAT. It works without NAT. I am also considering all possibilities such as the case the attacker is also behind the same NAT. In that case, there is a higher chance for the attacker to sniff the whole communication and even sends the query request immediately to the DNS server the same time as the client sends a request to the DNS server. Therefore, the client would be overwhelmed with many query response from the DNS server to its request. In that case, the simple example might not work too. Furthermore, if we assume that the algorithm is like the following, so that the server produces, everytime, the same cookie for the client and if the assumption is that the client knows the IP address of the server, then the attacker still has the possibility to spoof the source IP of DNS server because there is no actual server authentication and no one can proof that the message comes from the legitimate DNS server. [2] Server_cookie=Pseudo_function(client_cookie) Server_cookie=Pseudo_function(client cookie+client address+server secret) Doesn't really different. As a mistake I forgot to include the IP address of client. but in my
Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
In message 01d0c225$8c4d0260$a4e70720$@rozanak.com, Hosnieh Rafiee writes: So, you want such mechanism is implemented in NAT devices to protect all clients in that network, right? If not, the implementation of that in a single client behind the NAT, doesn't help all the clients inside that NAT network because the target is a public address of this device and other devices are not seen. This is , of course, according to your argument. It helps those clients behind the NAT that implement cookies. When the clients are not seen, I just wonder how the attacker can target them?? Clients talks to things other than DNS servers. The attacker gets the address of the address of the client from those transactions. NAT device doesn't know what to do with packets that coming from a xx machine that the source address is its own address without seeing any more information regarding ports, etc. so that it can redirect the requests to the target client. Either our definition from NAT device is different that is we are talking about two different device with two different functionality or there is a new generation of NAT devices that are so intelligent and know what to do when they receive undefined packets. There are two ends to the communication between the client and the DNS server it is querying. DNS COOKIES helps servers pick legitimate client queries out of spoofed traffic. Because if the attacker is using the public address of the NAT device then it is the NAT device who is the target of DoS. Then, if the mechanism wants to be applicable, then NAT device is the device which needs to implement this mechanism and not each client and add this option to any packet passes it that targets a recursive DNS server or store the state of server cookie. Having middle boxes modify packets is a *bad* *idea*. Might be, but this is also not applicable. But you just suggested that the NAT box do that. The client doesn't check the server cookie returned. It just stores it. The client checks the client cookie. The server checks the server cookie. If the client does not check the server cookie in a initial step, then why don't you send anything to server so that the server needs also to do some processes which, of course, need processing time and this is vital for the server. Take it easy and Only keep the state in your client similar to the following simple example and do not bother server as based on the arguments and the explanation in the draft, the involvement of the server doesn't help neither in authenticating the server nor doing any prevention of attacks. In other word, the server only do some steps that is not necessarily help the client. (this conclusion is according to your own explanation such as : The server does the steps so that it can identify the client when it talks to the server again. This both helps the client and server. The server is free to use different algorithms to generate it's key. DNS COOKIE doesn't specify the exact algorithm to use. Simple Example that has the same impact as dnsop-cookies mechanism: Client A sends a query to DNS server A. Client A stores the state (e.g. query for www.example.com status: sentresponse: false) The DNS server responds this client with the query response. Client checks its state storage and found that the response value was false. So it accepts the value from the server since it was waiting for a response. Then remove this state from its state storage as it no longer needs to ask any query. Now, the bad guy wasn't aware of those communication but, with a miracle, found that what IP address is used by Client A so that he can target this client who is behind the NAT. So the bad guy sends a lot of query requests to the server with spoofed client IP address as a source address. DNS server sends query responds to the victim client (Client A). Victim client only check its state storage and found that it never request for any query. So, it silently discard all queries. Now about miracle part, I do not know how the attacker can obtain the IP address of the client without sniffing the communication or has a possibility to eavesdrop. If he can eavesdrop, then he also can know all the information exchanged between client and the server. 99.999% of DNS recursive amplifiying attacks result from non DNS transactions which give away the address of the client. No sniffing required. Therefore, I am still confused that how this scenario, even the simplest one in my example, works behind the NAT. It works without NAT. I am also considering all possibilities such as the case the attacker is also behind the same NAT. In that case, there is a higher chance for the attacker to sniff the whole communication and even sends the query request immediately to the DNS server the same time as the client sends a request to the DNS server. Therefore, the client
Re: [DNSOP] [Gen-art] review: draft-ietf-dnsop-onion-tld-00
On 18 July 2015 at 04:25, Joel M. Halpern j...@joelhalpern.com wrote: Major issues: It seems to this reviewer that at least the definition of how to use these names, reference tor-rendezvous, needs to be a normative reference. It appears likely that tor-address also ought to be a normative reference. Minor issues: It is not clear that a github reference without version identification is sufficiently stable for a normative reference from an RFC. Hi Joel, hellekin started a discussion on the tor-dev list about getting a URI for the specs that can serve as a stable pointer to https://gitweb.torproject.org/torspec.git/tree/ and a version identifier. So we're working on this. -tom ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
When the clients are not seen, I just wonder how the attacker can target them?? Clients talks to things other than DNS servers. The attacker gets the address of the address of the client from those transactions. This is not highlighted in the draft which makes it confusing for the reader which causes to raise such question regarding NAT. Having middle boxes modify packets is a *bad* *idea*. Might be, but this is also not applicable. But you just suggested that the NAT box do that. Because I did not know how the attacker would target a single node behind the NAT without knowing the IP address (please refer to my last sentence). Therefore, I saw the target as a whole network or the NAT device. The client doesn't check the server cookie returned. It just stores it. The client checks the client cookie. The server checks the server cookie. If the client does not check the server cookie in a initial step, then why don't you send anything to server so that the server needs also to do some processes which, of course, need processing time and this is vital for the server. Take it easy and Only keep the state in your client similar to the following simple example and do not bother server as based on the arguments and the explanation in the draft, the involvement of the server doesn't help neither in authenticating the server nor doing any prevention of attacks. In other word, the server only do some steps that is not necessarily help the client. (this conclusion is according to your own explanation such as : The server does the steps so that it can identify the client when it talks to the server again. This both helps the client and server. The server does not keep the state. So, how it can identify the client next time when it starts to communicate to the server? This is not clear to me. I think I highlighted this fact in all my previous messages. If server thinks it communicated with this client before, only based on the fact that the client also included server cookie, then since the server does not store any state and each time the server might generate a new cookie, then the attacker can create a fake cookie using the similar way as the server generates its own cookie. That is : fake_server_cookie=(fake_client_cookie + IP client (victim) + attacker_secret) . It also generates a fake_client_cookie and in this way it pretends that it had a previous communication with server. Since server is not aware of the fact (no state in the storage), the server assumes that it had a communication with this client before. Therefore, it answers the attacker requests. The attacker does this with different values by requesting large queries from the server but with spoofed source IP address that is the source IP address of the client and still can perform the amplification attack. Now about the client, it will be overwhelmed with a lot of query responds from the server. since the client stored the previous server_cookie but the server_cookie might be different for each query. Therefore, the client might be puzzled and it starts processing server messages. So, the attacker seems to be successful. Therefore, the existence of server cookie did not help the client. So, I would back to the previous simple example that is client only mechanism (the following .. with considering the fact that the attacker no need to have a miracle to know the IP of the client). Simple Example that has the same impact as dnsop-cookies mechanism: Client A sends a query to DNS server A. Client A stores the state (e.g. query for www.example.com status: sentresponse: false) The DNS server responds this client with the query response. Client checks its state storage and found that the response value was false. So it accepts the value from the server since it was waiting for a response. Then remove this state from its state storage as it no longer needs to ask any query. Now, the bad guy wasn't aware of those communication but found that what IP address is used by Client A so that he can target this client who is behind the NAT. So the bad guy sends a lot of query requests to the server with spoofed client IP address as a source address. DNS server sends query responds to the victim client (Client A). Victim client only check its state storage and found that it never request for any query. So, it silently discard all queries. . All versions of BIND 9.10 support a variant of DNS COOKIE called SIT. This is a experimental compile option and is enabled by default in the Windows binaries we ship. https://source.isc.org for the git repository. Thanks Some editorial comments: Others might have different opinion, but while I was reading the draft, after reviewing introduction, suddenly the attacks starts which still there is nothing about the mechanism. So, I had to skip that section, review the mechanism and back to attack sections. So, maybe it
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On 16 Jul 2015, at 3:35 am, Francisco Obispo fobi...@uniregistry.com wrote: +1. I don’t think IETF should be chasing around widely used TLDs and trying to block them, it will be a never ending chase. We are trying to mitigate against unknowns and perhaps the best solution is to have the TOR folks apply for .ONION on the next round of TLD application and get a fully qualified delegation. Basically saying: If you need a globally unique identifier in the DNS, you must register it with the competent entity. If noy, you run the risk of having your users leak their queries and possibly connect to the wrong service. There are legitimate reasons why Tor users might not want privacy leakage even to the Tor Project itself. This should make a better proposal for standard, basically reinforcing the one DNS one Internet message, and not the “Make sure you are leaking enough queries so that the IETF can then reserve the name for you”. Who are we trying to protect with this remedy? TOR users? have they shown any interest in being protected? Given that Tor is designed for privacy protection, I think it is not unreasonable to assume that its users are interested in having their privacy protected. They may not be aware of this specific issue, but we can presume that they put some trust in the Tor project developers, who clearly want this draft to go through (given co-authorship). David Francisco Obispo CTO - Registry Operations http://www.uniregistry.com/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x4202 fobi...@uniregistry.link On 15 Jul 2015, at 12:24, Rubens Kuhl wrote: Em 15/07/2015, à(s) 16:21:000, hellekin helle...@gnu.org escreveu: On 07/15/2015 03:46 PM, Edward Lewis wrote: What if I copied the onion draft, changed all of the uses of onion to carrot, and then threw in some supporting documents to describe some other system that used carrot as it's base identifier? On the heels of onion's admission to the Special Use Domain Names registry, could I expect to have carrot admitted too? Do you have running code for carrot? The ToR source code, with all occurrences of onion replaced by carrot. Rubens ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop https://www.ietf.org/mailman/listinfo/dnsop___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On 15 Jul 2015, at 8:42 pm, Edward Lewis edward.le...@icann.org wrote: 4. Caching DNS Servers and 5. Authoritative DNS Servers I really believe that for DNS elements, there should be no change. By intent, the onion names are not to be presented to the DNS by what's in category 2 and 3 (Applications and Name Resolution API's respectively). I see placing any requirement on DNS elements - and by that I mean the software used to implement the DNS standard - as a bad idea, under the heading of permanent fix to a temporary situation. (I.e., Tor may not be permanent, if it is, as software matures onion names will not be in DNS queries.) I do think the privacy leakage issues from .onion names being treated as normal DNS queries are a significant issue, and likely to be one that will increase, not decrease, with broader Tor adoption and understanding. I agree that as software matures .onion names will not be in DNS queries - and i believe that specifying that behaviour in the RFC is an entirely appropriate way to accelerate that. Software adoption does not arrive at a mature state spontaneously, the first step to adoption is specifying what the correct behaviour should be. Unless a specific strong argument can be made that appropriate dealing with .onion names should only be in client libraries but not in DNS resolution libraries, changing resolution for .onion appears to be a useful way to mitigate a known problem. David signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies
In message 001201d0c288$317fe330$947fa990$@rozanak.com, Hosnieh Rafiee writes: When the clients are not seen, I just wonder how the attacker can target them?? Clients talks to things other than DNS servers. The attacker gets the address of the address of the client from those transactions. This is not highlighted in the draft which makes it confusing for the reader which causes to raise such question regarding NAT. Because it is irrelevent has to how the attacker chooses the address to attack. What is relevent is the impact the attack is happening and how a server can sort some/all legitimate traffic from the client out of the which is being spoofed. Having middle boxes modify packets is a *bad* *idea*. Might be, but this is also not applicable. But you just suggested that the NAT box do that. Because I did not know how the attacker would target a single node behind the NAT without knowing the IP address (please refer to my last sentence). Therefore, I saw the target as a whole network or the NAT device. Whether it is the client or the NAT it doesn't matter. They are one and the same as far as the world is concerned. The client doesn't check the server cookie returned. It just stores it. The client checks the client cookie. The server checks the server cookie. If the client does not check the server cookie in a initial step, then why don't you send anything to server so that the server needs also to do some processes which, of course, need processing time and this is vital for the server. Take it easy and Only keep the state in your client similar to the following simple example and do not bother server as based on the arguments and the explanation in the draft, the involvement of the server doesn't help neither in authenticating the server nor doing any prevention of attacks. In other word, the server only do some steps that is not necessarily help the client. (this conclusion is according to your own explanation such as : The server does the steps so that it can identify the client when it talks to the server again. This both helps the client and server. The server does not keep the state. So, how it can identify the client next time when it starts to communicate to the server? This is not clear to me. I think I highlighted this fact in all my previous messages. The client keeps state: the client cookie it sent and the server cookie returned. * If it is a recursive server this state is keep with things like the DNS PMTU of the server or if it supports EDNS. * If it is a stub resolver it could be kept in a shared memory segment that all of the stub resolvers instances can access or a well known file or there could be a lightweight daemon than just remembers cookies. In all cases appropriate r/w locking needs to be done. How it is kept is not important. Alternatively the stub could establish its own cookie pair by sending a QCOUNT=0 query with only a client cookie then send the query it want the answer to. If server thinks it communicated with this client before, only based on the fact that the client also included server cookie, then since the server does not store any state and each time the server might generate a new cookie, then the attacker can create a fake cookie using the similar way as the server generates its own cookie. That is : fake_server_cookie=(fake_client_cookie + IP client (victim) + attacker_secret) . It also generates a fake_client_cookie and in this way it pretends that it had a previous communication with server. Since server is not aware of the fact (no state in the storage), the server assumes that it had a communication with this client before. No. The server takes the fake_client_cookie + IP client (victim) + server secret + maybe parts of server cookie itself. Computes a server cookie and compares that with what was received. If and only if that matches (1 in 2^64) does the fake query get treated legitimate. Therefore, it answers the attacker requests. The attacker does this with different values by requesting large queries from the server but with spoofed source IP address that is the source IP address of the client and still can perform the amplification attack. It can attempt a amplification attack. As I stated earlier and in the document this is used in conjuction with other things like resource rate limiting. A client with a good server cookie avoids being rate limited. A cookie client with a bad/no server cookie gets a non/minimally amplified (add server cookie size) badcookie response rather then a TC=1 response after going through the rate limiter. A server can choose to always send badcookie if there is no server cookie in the cookie opt or there was a server cookie mis-match rather than adding the answer along with a good server cookie for queries received over UDP. This is possible whereas setting TC=1 on all UDP responses
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
There are plausible, if unlikely, circumstances in which a fork, not just of the Tor project software itself, but of the entire project including the specific URL, might happen. While this argument is an attempt at a reductio ab absurdum, I do not think it is - the circumstance described is unlikely, but not absurd. In other words, I agree with Ted. And as a much more active contributor to ICANN processes than IETF ones, I think Ted is right in characterisation of the appropriate interaction here. David On 16 Jul 2015, at 3:53 am, Ted Lemon ted.le...@nominum.com wrote: On 07/15/2015 11:46 AM, Edward Lewis wrote: What if I copied the onion draft, changed all of the uses of onion to carrot, and then threw in some supporting documents to describe some other system that used carrot as it's base identifier? On the heels of onion's admission to the Special Use Domain Names registry, could I expect to have carrot admitted too? 1. Do you seriously think DNSOP would have had consensus to advance such a draft? 2. If DNSOP did have consensus to advance such a draft, what would your objection be? I think that DNSOP would not advance such a draft unless a lot of reasonable people decided that they believed that .carrot was needed. And if DNSOP did indeed advance such a draft, I think that it would be the right thing to do to go to ICANN and say what do you guys think about this? I don't think we would be in a position to make demands, but we should be able to have the conversation. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
David Conrad wrote: ... With an exclusive registry: Them: Hey IANA, we're using .PAUL and here's the docs describing who we are and how. IANA: Um, sorry. Someone else is already using that label. Them: But we really like .PAUL and we have deployed a zillion instances that make use of .PAUL IANA: That's fine, but you're potentially creating an interoperability problem. Them: So tell the other guys to stop, since we've been using .PAUL since the early 1700s. etc. This smells like a hoop to me. it would be .PAUL.EXTERNAL, which noone in their right mind would really like or deploy a zillion instances of. granted, being in one's right mind has never been a requirement for developers of distributed systems technology, but still, the fact that it's a registry of 2LD rather than TLD changes how we should interpret the impact of a collision. someone could, as you say, deploy a zillion instances of an app that pirates .PAUL (or .DAVID) within the context of a local application or end system. this will not happen with .PAUL.ALT (or .DAVID.EXTERNAL). so: offering someone a chance to register that a conflict exists does not serve the purpose of advancing interoperability. It doesn't address the interoperability of non-interoperable domain name overlays. It does advance interoperability in the sense of improving the state of knowledge that the non-interoperable domain name overlays exist, how they operate, who runs them, etc. since the IETF gives guidance to implementers, i think it's wise to guide non-DNS naming implementers toward non-colliding names, and to guide end-system library and application implementers toward a dictionary of non-DNS exit gateways within the DNS namespace that mean the same thing for all of their users. It seems to me that by making the registry exclusive, you're trying to put the IESG/IETF/IANA in the role of gatekeeper of the non-interoperable domain name overlays. since we're now talking about what i'm trying to do, i'll tell you, because it isn't what you said. i'm trying to create a new IANA registry of 2LD's beneath an exit-gateway reserved TLD. and like all other IANA registries i know of, i'd like IANA to only register the use of a given code point for one use, and i'd like that use to be defined by some public document. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Request for Comments on Internet Draft about IoT DNS Name Autoconf
Manning, I will add this thread to DNSOP WG and 6lo WG. This is because a good target application area of my draft is 6lo environment. Today I discussed my draft with Samita, who is a co-chair of 6lo WG. She recommended to me that I can announce my draft to 6lo WG. DNSOP WG and 6lo WG, if you have time and interest in DNS autoconfiguration for constrained nodes (e.g., IoT devices), please attend 6MAN WG meeting from 1PM to 3PM tomorrow (at Congress Hall III). My presentation will be the last one. My draft on DNS name autoconfiguration for constrained nodes can be found in https://tools.ietf.org/html/draft-jeong-homenet-device-name-autoconf-03 Also, you two WG people can give me your comments by email. Thanks. Paul On Fri, Jul 17, 2015 at 6:26 AM, manning bmann...@karoshi.com wrote: The reason I ask is that the title is about DNS name autoconfig. It might be reasonable to run a parallel stream in DNSOPs, in the unlikely event of problems. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 16July2015Thursday, at 12:19, Mr. Jaehoon Paul Jeong jaehoon.p...@gmail.com wrote: Hi Manning, Sure, my proposal can be discussed in DNSOPS WG. Since my proposal uses IPv6 ND(neighbor discovery) and NI(node information) query, 6MAN WG will be a good place to discuss it first. After that, if needed, I will be able to introduce it to DNSOPS WG. Thanks. Paul On Fri, Jul 17, 2015 at 2:29 AM, manning bmann...@karoshi.com wrote: Ted et.al. Is there a good reason this is not being discussed in the DNSOPS WG? manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 14July2015Tuesday, at 11:16, Ted Hardie ted.i...@gmail.com wrote: Dear Professor Jeong, Thank you for sharing the update to your draft. I note that in the security section of your draft that you make the following proposal: to prevent the disclosure of location information for privacy concern, the subdomains related to location can be encrypted by a shared key or public-and-private keys. For example, a DNS name of smartphone1.living_room.home can be represented as smartphone1.xxx.home where xxx is a string of the encrypted representation of the subdomain living_room. First, I believe that there are more privacy concerns here than location privacy. The base format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unique_id.device_model.device_category.mic_loc.mac_loc.domain_name| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ proposes to include both the device model and a unique identifier. A naive implementation could easily select its serial number, which would clearly be problematic; even the device model may be an issue for certain cases (e.g. a medical device). Second, the delegation model here seems to require a consistent view of both device categories and location names. How do you see that being produced? Lastly, the privacy mitigation given is not yet clear to me. How would a user of the DNS determine how to decrypt the encrypted strings? If the point of the effort is autoconfiguration, relying on out-of-band configuration for this seems contrary to the goal. If you distribute the decryption keys within the DNS, however, you are likely to lose whatever privacy protection is provided. Can you explain this further? regards, Ted Hardie On Tue, Jul 14, 2015 at 6:31 AM, Mr. Jaehoon Paul Jeong jaehoon.p...@gmail.com wrote: Hi 6MAN WG, This is Paul. I would like to let you know a draft for IoT Device DNS Name Autoconfiguration: DNS Name Autoconfiguration for Internet of Things Devices (draft-jeong-homenet-device-name-autoconf-03) https://tools.ietf.org/html/draft-jeong-homenet-device-name-autoconf-03 Abstract This document specifies an autoconfiguration scheme for DNS names of Internet of Things (IoT) devices, such as appliances and sensors. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's category and model in wired and wireless networks (e.g., home, office, shopping mall, smart grid, and road network). This DNS name lets IoT users (e.g., home residents and customers) easily identify each device for monitoring and remote-controlling it in a target network. This draft is a follow-up IETF draft of RFC6106-bis for IPv6 RA RDNSS and DNSSL options for IPv6 Host DNS Configuration: https://tools.ietf.org/html/draft-jeong-6man-rdnss-rfc6106-bis-00 For this draft, three organizations (i.e., SKKU, ETRI, and Jubix) are developing a prototype of our proposed IoT DNS
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On 17 Jul 2015, at 10:52 pm, hellekin helle...@gnu.org wrote: On 07/17/2015 11:32 AM, David Conrad wrote: No. .LOCAL was not already in the root zone. .FOO is. *** Therefore the .FOO label is not available for Special-Use anymore, end of story. A Special-Use name cannot be an already registered name in the root zone. If you referring to e.g., .corp that has proposals both for Special-Use and normal ICANN assignation, this is a distinct issue, as the label is not yet in the root zone, and there are good reasons why it would be a bad idea to put it there (already existing name conflicts) but not compelling (if the .corp registrar is ready to deal with the extra load, or if capturing all the leaked requests from random devices around the world is not deemed to pose a security issue...). This is an entirely different matter. Of course, ICANN has already determined that .corp does pose a security issue of sufficient significance that .corp will not be delegated. Now if there's a prior request for Special-Use and an ICANN registration appears after the fact, that would be a problem: if someone would ask to register .onion or .gnu today, we'd run into the problem you're suggesti ng. And objections to delegation would almost certainly be raised inside ICANN processes and dealt with there if that happened. While it is worth considering whether ICANN gTLD delegation and IETF Special-Use consideration processes could end up on a collision course in theory, in practice, it is fairly unlikely. There is significant overlap between the two organisations from board level on down such that the two are unlikely to be considered in isolation. The ICANN board obviously considered the issue (as it was mentioned in correspondence from the board to the community, which I am unable to locate currently due to ICANNs execrable web site search/document management), and chose for the moment to, rather than adding formal mechanisms, to encourage members of the ICANN community to monitor discussions in DNSOP (which was the catalyst for my joining DNSOP). I personally think that informal mechanisms will be enough for the moment, and I’m sure if it proves to be inadequate that other more formal coordination mechanisms can be considered. David signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
As someone with moderate experience in both DNS and web server configuration, FWIW I found the meaning relatively obvious. The notion that HTTP Host headers might be used to change web server response independent of name resolution (e.g. that two names that return identical responses to every possible DNS query, but produce different web server responses) has been fairly intrinsic to how web servers operate for a couple of decades now, and this seems a simple but useful clarification regarding how this operates for .onion names to me. David On 17 Jul 2015, at 11:17 pm, Eliot Lear l...@cisco.com wrote: Hi Richard, Thanks for the explanation. Please see below. On 7/17/15 4:38 PM, Richard Barnes wrote: On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear l...@cisco.com wrote: I have no particular objection to the concept here, but I do have a question about one sentence in the draft. Section 1 states: Like Top-Level Domain Names, .onion addresses can have an arbitrary number of subdomain components. This information is not meaningful to the Tor protocol, but can be used in application protocols like HTTP [RFC7230]. I honestly don't understand what is being stated here, or why a claim is made about HTTP at all in this document. Are we talking about the common practice of www.example.com == example.com? And what significance does that last phrase have to the document? I made a comment on this to the authors earlier, and they decided to leave it as-is :) The idea is that TOR routing will only use the first label after .onion, but if you're using the .onion name in an application, that application might use the whole name. For example, if you put http://mail.example.onion/;, TOR will route on example.onion, but the HTTP Host header might be mail.example.onion. - I just leave the IESG and WG with the comment that two of us old timers are trying to divine the meaning of those two sentences, and that can't be good for others with (even) less clue. Personally I think the easiest approach is to remove those two sentences, but if others really disagree, then a bit more clarity seems in order. Eliot ___ DNSOP mailing list DNSOP@ietf.org mailto:DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
It seems to me to be a situation similar to that with MIME types - there is value in having a well understood part of the namespace for unregistered experimentation on an FCFS basis. David On 19 Jul 2015, at 3:08 am, John R Levine jo...@taugh.com wrote: the ietf's stated purpose is to ensure interoperability. for many years we all treated that as make sure everybody agrees as to the meaning of what's on the wire. the .ALT (or .EXTERNAL or whatever) specification will not change what's on the wire, but its purpose is still to ensure interoperability. simply put, we want any internet-capable device to have the same experience when using non-internet naming. Sure, we all want that, but an IANA registry that only lets one entity register each name would be counterproductive, because names have semantic meaning. Nobody cares whether they get rrtype number or port number 42103 or 42104. But if two people show up with something that uses sex.alt, and IANA tries to tell one of them to use sey.alt instead, fat chance. A simple FCFS will be full of squatters, not actually doing anything with the names, but hoping, probably wrongly, that the name will be valuable some day. (See the first couple of thousand registrations in any of ICANN's new TLDs for an example of this.) Furthermore, let's say someone's squatting on sex.alt, someone else builds a P2P* service, looks around, sees that nobody's actually using sex.alt, so he calls his sex.alt. Now the registry is actively wrong. If we try to make rules about hoops one has to jump through to register a *.alt service, we're back exactly where we are now with .onion. People will ignore them until their critical mass becomes a fait accompli, so why bother. If two people show up about the same time with something called sex.alt, how are we supposed to decide who wins? We get to have our own IETF-lite version of the .africa fiasco currently happening at ICANN. And, of course, if we do pick one, the other will still keep calling itself sex.alt and there's nothing we can do about it. That's why I think that a FCFS non-exclusive registry could be useful so that people who want to avoid collisions can find infor that lets them assess the collision risk for their favorite names, and it doesn't matter whether it's at IANA or somewhere else since it's just voluntary advice. Since we are not the Domain Name Police, if people want to create services with names that collide, they will do so. It'd be nuts to pretend otherwise. R's, John * - Porn 2 Porn, of course ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
