[DNSOP] Working Group Last Call for draft-ietf-dnsop-cookies
All Donald and Mark have worked out the issues on the DNS Cookies draft, mostly around the issue of returning an error code (no), and getting an official Option-Code (10). This starts a Working Group Last Call for draft-ietf-dnsop-cookies Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/ https://tools.ietf.org/html/draft-ietf-dnsop-cookies-04 Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons. This starts a two week Working Group Last Call process, and ends on Thursday July 16th, 2015. thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
Hi, I think that Andrew's effort to distinguish between a domain name and a DNS name is useful. It gives us some clear terminology to use to discuss domain names that wish to use a non-DNS name resolution method. RFC6761 introduces a mechanism for the handling of these types of cases. In the recent cases of .onion, .gnu, .zkey etc. we have software using domain names but wishing to use a non-DNS name resolution mechanism. This is a hand in glove use of RFC6761. For persons wishing not to allow the use of RFC6761 for these names, it would seem that you have two options: 1. Invalidate RFC6761 indicating it was a mistake. This is not a disaster, mistakes are made and sometimes need to be rectified. 2. Form a different community for the assessment of these issues, and decide not to participate in that process. Thus, you are not allowing the use. Option 2 may not be such a silly idea. Some members of the community made it clear that they do not wish for DNSOP to be a clearing house for RFC6761. I assume that .gnu, .zkey, .bit communities would have the patience to wait for the formation of an alternative processing mechanism, but there is time pressure on .onion due to the upcoming work with certificates. Thus, it would seem that a decision is required from this community for the .onion case. Needless to say, I support all of these cases where software is using the domain name syntax but using a non-DNS name resolution mechanism. I provide that support because they are addressing the issue of privacy which the greater IETF community embraced with RFC7258. The DPRIVE WG are working on privacy enhancements *within* the DNS system. It is a difficult problem, though many useful contributions are emerging. The above non-DNS using softwares approach the same issue in a different manner: dont use DNS at all. The advantage of this approach is that all of the challenges that DPRIVE are wrestling with are not encountered at all. The only requirement is the registration via RFC6761. Hugo Connery -- 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. From: DNSOP [dnsop-boun...@ietf.org] on behalf of Andrew Sullivan [a...@anvilwalrusden.com] Sent: Thursday, 2 July 2015 03:42 To: dnsop@ietf.org Subject: 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 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
Paul Wouters p...@nohats.ca wrote: You would only add it to the question for DNSKEY of the root. Yes. Maybe only after you determined a validation failure, so you clearly have the wrong trust anchor. No, the point of this option is to signal to the root what trust anchors are in use by the population of validators, before a rollover happens. It is like the algorithm signalling option, RFC 6975. (Which seems to be mostly unimplemented... why?) It seems in general, having some special record signed by only the new key seems a nicer solution, That cannot work. http://www.ietf.org/mail-archive/web/dnsop/current/msg14664.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Dover, Wight, Portland, Plymouth: Cyclonic, mainly southwest, 4 or 5. Slight or moderate. Thundery showers. Moderate, occasionally poor. ___ 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
I hope you don't mind replying publicly to this, because I think you did a very good thing describing it as a one-act play. (Seriously.) Kinda like why we parody Harry Callahan at times. (That's Dirty Harry's name for those under the age of, oh 50.) On 7/1/15, 16:59, Warren Kumari war...@kumari.net wrote: (Applicant enters stage left) But what if the applicant's name is Godot (and never appears on stage)? [https://en.wikipedia.org/wiki/Waiting_for_Godot] Let's say someone does this. They squat on .foo. They never engage the IETF. Traffic is seen for .foo. A lot of DNS queries to 8.8.8.8 ask for foo. names and data, I mean. The operators of recursive servers have no idea what is generating the ever-growing queries for foo. and so, like other annoying queries, begin to filter them. One day someone else wants to launch a .FOO TLD. (Stay tuned for the sequel Universal Acceptance) The objective of a registry is to map object to entity for the sake of (among a few services) uniqueness. The latter part of that statement is often forgotten. The uniqueness is not just to protect the entity to which the object is mapped, but to protect all others from running into it. Collisions are not always hi-jacks, where the collider wants to tackle the object, sometime they are like tripping hazards where the collider just didn't see it or have a chance to see it. One red herring here is that there's a domain name market. There is. To the IETF that should simply mean that the likelihood of collisions is higher than it was without a market. And yes, ICANN has processes for dealing in that market. But that's not important here. There's one other factor in all of this, coming in out of the blue. I recall a talk at DNS-OAC in spring of 2013 where someone tracked down a source of query traffic that could be categorized as annoying. After much effort, the source was a music app using the DNS as a ping/keep-alive service, meaning the app, which had not reason to use DNS much, know that by repeatedly sending traffic it kept up tunnels, etc. The point is - the presenter went though a lot of trouble and only with luck, identified the source. This is part of the desire for a registry - so we can figure out where and why traffic is coming into servers. That talk - I just can't find it...I thought it would be here, but I don't see it: https://indico.dns-oarc.net/event/0/contributions Or maybe I'm making it all up. That's why I still think there's a need, even with an alt-TLD, for a process to register special use names, special in a technical way. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
On 7/2/15, 6:02, DNSOP on behalf of Hugo Maxwell Connery
dnsop-boun...@ietf.org on behalf of h...@env.dtu.dk wrote:
Hi,
I think that Andrew's effort to distinguish between a domain name and
a DNS name is useful. It gives us some clear terminology to use to
discuss domain names that wish to use a non-DNS name resolution
method.
Until this message, I wasn't clear on Andrew's distinction - we have been
talking off-list for the past few days too.
To me a domain name is: a sequence of bits that, when rendered in hex
notation, can look like this:
0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00
That is what is sent over the wire, through ports and is deposited in
memory of name servers. Note the lack of dots. And this is why I can't
see a difference between domain names and DNS names. To me, they are one
in the same.
This dates back to a discussion had while the labs I was in was developing
DNSSEC code. Our boss (Russ Mundy) made the statement that there are two
versions of a domain name, on-the-wire and in-the-file and it was the
on-the-wire format that mattered. Later in my career I worked with a firm
that developed it's own DNS code based on some legacy stuff from it's
start-up days. The start-up operated on the in-the-file format,
converting to and from on-the-wire format constantly. This was not a good
approach.
So when I hear domain name I think of the format that includes an octet
with flags and a number and then that number of octets of data,
terminating with a null octet. What is seen in files is just a
transliteration of that, abc.example. is just a conventional way to
represent the domain name above.
Now, if times have changed and a broader audience thinks abc.example. is
a domain name, there's a need to document that. In an old RFC there are
rules for representing a domain name in a file, rules that are
inconsistently understood and applied. Maybe it's not times, it's
perspectives. I'm coming up through the DNS, I didn't come across the DNS
from application space.
What I mean by rules inconsistently applied is a case of apparently
mis-aligned RFCs on ENUM. In one RFC, domain names were presented as
conversions to ASCII and the other following the rules of the old RFC for
escaping characters. Specifically, a back-slash was the issue, in one RFC
it was bare, in the the other escaped, and this difference caused
implementers of ENUM code headaches.
(I should look this up. I lost the notes on that incident, but probably
can try to dig up the references.)
I'll ask this, are these (thought to be) domain names:
\097\098\099.example. { 97 is the decimal equivalent of 'a' in RFC 20's
ascii table }
\a\b\c.example.
example.中国. {latter two characters are Chinese, meaning the country of
China}
现在我跟老婆住华盛顿可是以后我飞到IETF.练习 { a sequence of Chinese
charaters, IDNA2008 code
says label too long }
The latter is a placeholder for names that would be too long for the DNS
but otherwise look like, in a file, a domain name. This is said to be
true in Tor's use.
I am not asking to be facetious. I have had to deal with these questions
over the years. The latter I have code to test because I'd been asked to
look at official names of geographic regions and whether what would
'appear' to be a domain name from that could possibly be carried across
port 53.
If there is a distinction to be made between domain names and DNS names,
the former needs to be defined first. What are the rules in an http:// or
ftp:// URL? Colloquially I think the first name is a 'domain name' but I
have never been able to trace that down. I doubt that the 'domain name'
there is ever processed in on-the-wire format (as I started with) until
the DNS stub resolver accepts the request and spits out something to a
recursive server at port 53 somewhere.
(This omits the other under-worldly distinction of what names are eligible
for registration, etc., which is a distinction I've had to deal with. In
a world where one can write in any script with any kind of pen or pencil,
you have to know where do, um, draw, the line. IDNA2008? Punycode?
Different rules for different systems? And, is the domain of the
problem all code, all protocols, or what's in common use on the global
public Interent?)
smime.p7s
Description: S/MIME cryptographic 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/02/2015 10:05 AM, Edward Lewis wrote: You're right. To underscore, it's because of the groups that don't engage, and have no responsibility to do so, that the IETF has to defend itself. It wouldn't take much work Keep in mind that the IETF isn't a thing, it's a collection of people volunteering time. What I mean to say, not much work, but it's like trying to jump out of the ocean back into a boat. I could not agree more with Str4d. Processes are not at fault: aren't we having a rough consensus about the Internet as an open society? For your information, draft-grothoff-iesg-special-use-p2p-names-00 was published on *November 14, 2013* [0]. It has been submitted to 4 revisions to date, without counting the newly split drafts at the request of DNSOP list members into a draft per system (.bit [1], .exit [2], GNS [3], and .i2p [4]). As a final comment to help you catch up with the process, the .alt draft [5] first appeared on June 06, 2015, and the original mention of .onion was removed from its fifth revision following my request to confirm that .onion was not covered by this draft (per the draft author.) I think you know this because your comments were also included in this version of the .alt draft. I am very surprised that you did not read the P2PNames draft, and hope you will now read the 5 drafts that came from it (I include .onion [6] to the 4 mentioned above). Regards, == hk P.S.: As Christian Grothoff mentioned, I was interested in making these 5 drafts leanier, following the .onion model, and bring the (common) details into an informational RFC instead. If you think 5 drafts are too much reading, that might help, especially as there's a lot of redundancy from one to the next. [0]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam es/00/ [1]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-bit / [2]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-exi t/ [3]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-gns / [4]: https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-i2p / [5]: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ [6]: https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVlUYyXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9zpIP/3QJF7Eni4RrzwAn5U3ITnqo vsv/cTcVYTm2EybW3mFaY/UeE868HyHrsF0mXOIxwm/B6lFCAKA47B5m+zvqhRwA I1euxD9L/KOoB/8//sE+JLzKffiwGPaI2MY6r3Wiqb5ivijy1sVVuwr8GV2QdvoD Nvflcnu+iXX3IQJpZTDxrrmKjYIdgXxCxKPKYquf4kE3cMWv/5sEolYvTH1eHlLV MBGzzKZntE487u0RGEiym0teE0xV3U09Ln7cpppMmKrrKs3UkcXfqFbB+fhKHP+N J54Pif+ndiMeBAcYuoj4/OXtT+x1r3rOR8PLgUvdlYfBsJpjOlREAVqDP/c9R1sW PWkSkrBmo1hTkQv5ZPt/EBc6Fiovq3k0ptnO3GXn4XOT1udXarlAXpZm7KvzY7Sc DG6Q2EXM8//w4jwfC3mBt+jFEskijEh6G2sNo0z8lBsgyU9EZuSkUGMtT3c1nLaX jnV0Qd90tpD9tP/dGk/U4S8V4Wg9fhBxlDbMYiEFRttaGdL4MGFXoSDcHLuqDTTX QAtDx2kvR/yhLJY5OHO1qGvTjixcfMz82COrRCEsczH4psjS/iRziT1DlGX2aMQr 6kSOPq0EtabdfYwsHSETfh4KC1DfzzIEVlvFen3hs9sIrj631HACoZfMLNYcjbmH vNO8NaLUMJsIIi9eniQ2 =0u6r -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Citation for that ENUM error Re: back to: Some distinctions and a request
Edward Lewis edward.le...@icann.org wrote: RFC 5483, section 2.4 talks about this (and gives an example plus a citation of an errant RFC) - although related to regular expressions in NAPTR Resource Record RDATA fields, not to the domain name. This does mention the impact on on-the-wire DNS representations. In the example, the presence of a '+' is the issue in the NAPTR-held regular expression. But the same would be true if it were inside a domain name. No, plus is not a special character in master files so it does not need to be quoted. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Westerly 3 backing southwesterly 4 or 5 in northwest, otherwise northeasterly 4 or 5, occasionally 6 later. Moderate. Fair. Good. ___ 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, 18:37, DNSOP on behalf of str4d dnsop-boun...@ietf.org on behalf of st...@i2pmail.org wrote: 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. I don't read everything, and I'm not usually focusing on this. That's the trouble with volunteers. 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) That's fair. This is all volunteer. (That is why it's up to the IETF to define how to react.) I certainly don't dislike standards processes. Of course not - you are engaging with the process. What I _do_ dislike is inconsistency and poor documentation/education. Then you've come to the wrong place. ;) 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.) You're right. To underscore, it's because of the groups that don't engage, and have no responsibility to do so, that the IETF has to defend itself. It wouldn't take much work Keep in mind that the IETF isn't a thing, it's a collection of people volunteering time. What I mean to say, not much work, but it's like trying to jump out of the ocean back into a boat [kinda like this: http://www.bbc.com/sport/0/american-football/30744474]. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Citation for that ENUM error Re: back to: Some distinctions and a request
On 7/2/15, 8:51, Edward Lewis edward.le...@icann.org wrote: What I mean by rules inconsistently applied is a case of apparently mis-aligned RFCs on ENUM. In one RFC, domain names were presented as conversions to ASCII and the other following the rules of the old RFC for escaping characters. Specifically, a back-slash was the issue, in one RFC it was bare, in the the other escaped, and this difference caused implementers of ENUM code headaches. RFC 5483, section 2.4 talks about this (and gives an example plus a citation of an errant RFC) - although related to regular expressions in NAPTR Resource Record RDATA fields, not to the domain name. This does mention the impact on on-the-wire DNS representations. In the example, the presence of a '+' is the issue in the NAPTR-held regular expression. But the same would be true if it were inside a domain name. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning wrote: There in lies the problem. These systems have no way to disambiguate a local v. global scope. It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets and no way to attempt DNS resolution. Or they need to ensure that DNS resolution occurs after every other “name lookup technology” which is not global in scope. I don't understand this point. Since Onion hidden service names are based on hashes derived from public keys surely they're globally scoped (barring hash collisions)? -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 16:44, Robert Edmonds edmo...@mycre.ws wrote: Have a look at the later HTTP/1.1 RFCs (7230) and the URI generic syntax RFC (3986). RFC 7230 defines http URIs, but it relies on the URI generic syntax (RFC 3986) to define uri-host's, and that specification explicitly declines to require that domain-looking-strings be Internet DNS names: 3.2.2. Host [...] This specification does not mandate a particular registered name lookup technology and therefore does not restrict the syntax of reg- name beyond what is necessary for interoperability. […] . However, a globally scoped naming system, such as DNS fully qualified domain names, is necessary for URIs intended to have global scope. URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length. [...] -- Robert Edmonds There in lies the problem. These systems have no way to disambiguate a local v. global scope. It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets and no way to attempt DNS resolution. Or they need to ensure that DNS resolution occurs after every other “name lookup technology” which is not global in scope. Paul Vixies point about an escape method not being apparently visible comes to mind. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
agreed. but a “reserved string” registry isn’t the way to do that… at least in a scaleable fashion. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 10:34, Paul Vixie p...@redbarn.org wrote: manning wrote: ... STRONGLY suggests that “domain-looking-string” is , in fact, a host that is identified using the Internet DNS. i agree with this interpretation, which means, it's the spec itself that's wrong, not hugo's interpretation of it. the internet people didn't love .UUCP addresses either but that didn't stop them from working. what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying we are the only thing you can use. -- Paul Vixie ___ 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] back to: Some distinctions and a request
the ^G registration was done prior to RFC 1123 being written. I think, this whole discussion (particularly Ed Lewis’s POV about wire formats v. readings from RFC 1034 suggest reopening the can’o’worms that was/is the IDN debate and 8bit clean, native Unicode, etc. Regarding Andrew S. recognition that the horse has left the barn (.local, .onion, etc.) there are two options open: 1) close the door before others escape and completely pollute the watershed, 2) throw in the towel and give up manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 15:26, Mark Andrews ma...@isc.org wrote: In message d1bafc60.ca8f%edward.le...@icann.org, Edward Lewis writes: On 7/2/15, 13:34, DNSOP on behalf of Paul Vixie dnsop-boun...@ietf.org on behalf of p...@redbarn.org wrote: manning wrote: ... STRONGLY suggests that =E2=80=9Cdomain-looking-string=E2=80=9D is , in fact, a host that is identified using the Internet DNS. i agree with this interpretation, which means, it's the spec itself that's wrong, not hugo's interpretation of it. the internet people didn't love .UUCP addresses either but that didn't stop them from working. what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying we are the only thing you can use. At the risk of further annoying Andrews ... if there was a definition of domain name in contexts external to the DNS, that would be helpful. Plus, in each context, what are the escape rules, if needed? E.g., At one time, some funny guy tried to register ctrl-G as a TLD. (He knows who he is.) How would that be written in a URL? In a domain name: \007 (RFC 1034 presentation encoding) In a host name: not possible as it is outside the allowable syntax. In a url it would depend upon the scheme. It would not be valid for http:, https: or mailto: to start with as all three are restricted to using hostnames. For those schemes where it is valid input %07. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
On 2July2015Thursday, at 18:21, Robert Edmonds edmo...@mycre.ws wrote: manning wrote: There in lies the problem. These systems have no way to disambiguate a local v. global scope. It seems like the obvious solution is to ensure that these nodes do NOT have global scope, i.e. No connection to the Internets and no way to attempt DNS resolution. Or they need to ensure that DNS resolution occurs after every other “name lookup technology” which is not global in scope. I don't understand this point. Since Onion hidden service names are based on hashes derived from public keys surely they're globally scoped (barring hash collisions)? -- Robert Edmonds If they _are_ globally scoped, what part of the local system decides which namespace to use, the ONION, the LOCAL, the P2P, the BIT, the BBSS, the DECnetV, the IXP, or the DNS… where is search order determined? Does first match in any namespace win? What is the tiebreaker when there are label collisions between namespaces? /bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
On Thu, Jul 02, 2015 at 10:34:42AM -0700, Paul Vixie wrote: what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying we are the only thing you can use. The Internet _has_ done that. Unfortunately (and I do think it's unfortunate), the Internet did this by in-band signalling in things that go in domain name slots in protocol strings. That what local. (and, given its deployment, onion.) are doing. I don't have to like it to recognize that this has happened, and that as people who are trying to design systems to maximize interoperability we have to cope with those facts. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
Hi Mr Lewis, and list, I believe that you are making a category error here. The key point is that the softwares that are using the domain name (dot separated network identifier) labeling system do not wish to use the DNS architecture for name to address resolution, at all. However, they may wish to use the excellent transport mechanisms that IETF have defined over the years, including the latest version(s) of TLS. I come back to this below when considering the failure mode of communication to a URI. Additionally, they wish to protect the privacy of their users by having the DNS reject to resolve these names. We have a mechanism which reliably translates www.example.org into some on-the-wire byte representation and works. This does not need to change, or even be investigated. Here is what I believe the non-DNS resolution softwares want: 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) within the root zone as not a domain. i.e if anyone asks the answer for anything in or under that pTLD the answer is NXDOMAIN. 2. Iterative resolution software to also be aware of this, such that they have a permanent in cache response to hand out NXDOMAIN without bothering the root zone's resolvers (and exposing the query). 3. qname minimisation to be approved and implemented. In this case, if 2. is not achieved the exposure of the end user system is dramatically limited. All of the above is worst case usage from these softwares. Normal operation is that the DNS architecture does not even see these name resolutions happening -- they use whichever mechanism they have designed and implemented -- the end user is satisfied (assuming their mechanism works) and the DNS knows nothing. Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ When entered into the Tor browser, the DNS sees absolutely no traffic, at all, irrespective of whether the domain name exists. E.g if asdfasdfasdfasdf.onion is not defined within the Tor network, still the DNS sees nothing. However, some configuration of a recently defined TLS transport is used (https). When opened with a regular browser, the use of the Tor network is exposed, as described above. The communication will fail, as the asdfasdfasdfasdf sub-domain is not registered (and hopefully not registerable). We are talking about *how* it fails, and reducing the leaking of information in that process. All of these on-list discussions are about point 1. above; Negative registration in the root zone via RFC6761. Steps 2 and 3 are, I expect, also on the agendas for these overlay networks, because they care about the privacy of their community. If point 2 could be universally achieved, points 1 and 3 are moot. But, that is never doing to happen, thus the current approach. Sincerely, Hugo Connery NB: I am not a member of the community for any of these networks, and I certainly dont speak on their behalf. I do use Tor regularly. From: Edward Lewis [edward.le...@icann.org] Sent: Thursday, 2 July 2015 14:51 To: Hugo Maxwell Connery; Andrew Sullivan; dnsop@ietf.org Subject: Re: [DNSOP] back to: Some distinctions and a request On 7/2/15, 6:02, DNSOP on behalf of Hugo Maxwell Connery dnsop-boun...@ietf.org on behalf of h...@env.dtu.dk wrote: Hi, I think that Andrew's effort to distinguish between a domain name and a DNS name is useful. It gives us some clear terminology to use to discuss domain names that wish to use a non-DNS name resolution method. Until this message, I wasn't clear on Andrew's distinction - we have been talking off-list for the past few days too. To me a domain name is: a sequence of bits that, when rendered in hex notation, can look like this: 0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00 That is what is sent over the wire, through ports and is deposited in memory of name servers. Note the lack of dots. And this is why I can't see a difference between domain names and DNS names. To me, they are one in the same. This dates back to a discussion had while the labs I was in was developing DNSSEC code. Our boss (Russ Mundy) made the statement that there are two versions of a domain name, on-the-wire and in-the-file and it was the on-the-wire format that mattered. Later in my career I worked with a firm that developed it's own DNS code based on some legacy stuff from it's start-up days. The start-up operated on the in-the-file format, converting to and from on-the-wire format constantly. This was not a good approach. So when I hear domain name I think of the format that includes an octet with flags and a number and then that number of octets of data, terminating with a null octet. What is seen in files is just a transliteration of that, abc.example. is just a conventional way to represent the domain name above. Now, if times have changed and a broader audience thinks abc.example. is a domain name, there's a need to document that. In an old RFC there are
Re: [DNSOP] back to: Some distinctions and a request
manning wrote: ... STRONGLY suggests that “domain-looking-string” is , in fact, a host that is identified using the Internet DNS. i agree with this interpretation, which means, it's the spec itself that's wrong, not hugo's interpretation of it. the internet people didn't love .UUCP addresses either but that didn't stop them from working. what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying we are the only thing you can use. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
manning, The defense is the defense of the privacy of their community due to the commonality of the URI format. (protocol)://(domain-looking-string)/(path). Open that with the right software and all is good, no privacy is lost, and the DNS is not involved. Open it with DNS based software and you leak information / lose privacy. It is that simple. The negative registration is to minimize info leakage and loss of privacy, which apparently we care about. Hugo Connery -- 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. From: DNSOP [dnsop-boun...@ietf.org] on behalf of manning [bmann...@karoshi.com] Sent: Thursday, 2 July 2015 18:40 To: Hugo Maxwell Connery Cc: dnsop@ietf.org Subject: Re: [DNSOP] back to: Some distinctions and a request If that is the case, that these folks don’t want to use the DNS name-address resolution at all, then there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS for its intended purpose. If House Finch Feathers OY applies to ICANN for the .ONION TLD, there should be zero objection, since other use is outside the scope of the DNS. the use of a “reserved label” registry simply for “defensive” purposes is properly outside the scope of the IETF goal of defining and developing Internet Protocols. As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate effort, but the facts are that overlaps occur in real life (see also: acronym overload) and the name space in question is the DNS view of the name space, not domain name space en-toto. (whee - hows that for a run-on sentence!) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:04, Hugo Maxwell Connery h...@env.dtu.dk wrote: Hi Mr Lewis, and list, I believe that you are making a category error here. The key point is that the softwares that are using the domain name (dot separated network identifier) labeling system do not wish to use the DNS architecture for name to address resolution, at all. However, they may wish to use the excellent transport mechanisms that IETF have defined over the years, including the latest version(s) of TLS. I come back to this below when considering the failure mode of communication to a URI. Additionally, they wish to protect the privacy of their users by having the DNS reject to resolve these names. We have a mechanism which reliably translates www.example.org into some on-the-wire byte representation and works. This does not need to change, or even be investigated. Here is what I believe the non-DNS resolution softwares want: 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) within the root zone as not a domain. i.e if anyone asks the answer for anything in or under that pTLD the answer is NXDOMAIN. 2. Iterative resolution software to also be aware of this, such that they have a permanent in cache response to hand out NXDOMAIN without bothering the root zone's resolvers (and exposing the query). 3. qname minimisation to be approved and implemented. In this case, if 2. is not achieved the exposure of the end user system is dramatically limited. All of the above is worst case usage from these softwares. Normal operation is that the DNS architecture does not even see these name resolutions happening -- they use whichever mechanism they have designed and implemented -- the end user is satisfied (assuming their mechanism works) and the DNS knows nothing. Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ When entered into the Tor browser, the DNS sees absolutely no traffic, at all, irrespective of whether the domain name exists. E.g if asdfasdfasdfasdf.onion is not defined within the Tor network, still the DNS sees nothing. However, some configuration of a recently defined TLS transport is used (https). When opened with a regular browser, the use of the Tor network is exposed, as described above. The communication will fail, as the asdfasdfasdfasdf sub-domain is not registered (and hopefully not registerable). We are talking about *how* it fails, and reducing the leaking of information in that process. All of these on-list discussions are about point 1. above; Negative registration in the root zone via RFC6761. Steps 2 and 3 are, I expect, also on the agendas for these overlay networks, because they care about the privacy of their community. If point 2 could be universally achieved, points 1 and 3 are moot. But, that is never doing to happen, thus the current approach. Sincerely, Hugo Connery NB: I am not a member of the community for any of these networks, and I certainly dont speak on their behalf. I do use Tor regularly. From: Edward Lewis [edward.le...@icann.org] Sent: Thursday, 2 July 2015 14:51 To: Hugo Maxwell Connery;
Re: [DNSOP] back to: Some distinctions and a request
Hum… “domain-looking-string” … Per RFC 1945, we read: 3.2.2 http URL The http scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs. http_URL = http: // host [ : port ] [ abs_path ] host = A legal Internet host domain name or IP address (in dotted-decimal form), as defined by Section 2.1 of RFC 1123 port = *DIGIT” So then the question on the table is, What is a “legal host domain name”? RFC 1123, using SMTP as the example, says: 5.3.5 Domain Name Support SMTP implementations MUST use the mechanism defined in Section 6.1 for mapping between domain names and IP addresses. This means that every Internet SMTP MUST include support for the Internet DNS.” This STRONGLY suggests that “domain-looking-string” is , in fact, a host that is identified using the Internet DNS. manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:59, Hugo Maxwell Connery h...@env.dtu.dk wrote: manning, The defense is the defense of the privacy of their community due to the commonality of the URI format. (protocol)://(domain-looking-string)/(path). Open that with the right software and all is good, no privacy is lost, and the DNS is not involved. Open it with DNS based software and you leak information / lose privacy. It is that simple. The negative registration is to minimize info leakage and loss of privacy, which apparently we care about. Hugo Connery -- 'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman. From: DNSOP [dnsop-boun...@ietf.org] on behalf of manning [bmann...@karoshi.com] Sent: Thursday, 2 July 2015 18:40 To: Hugo Maxwell Connery Cc: dnsop@ietf.org Subject: Re: [DNSOP] back to: Some distinctions and a request If that is the case, that these folks don’t want to use the DNS name-address resolution at all, then there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS for its intended purpose. If House Finch Feathers OY applies to ICANN for the .ONION TLD, there should be zero objection, since other use is outside the scope of the DNS. the use of a “reserved label” registry simply for “defensive” purposes is properly outside the scope of the IETF goal of defining and developing Internet Protocols. As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate effort, but the facts are that overlaps occur in real life (see also: acronym overload) and the name space in question is the DNS view of the name space, not domain name space en-toto. (whee - hows that for a run-on sentence!) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:04, Hugo Maxwell Connery h...@env.dtu.dk wrote: Hi Mr Lewis, and list, I believe that you are making a category error here. The key point is that the softwares that are using the domain name (dot separated network identifier) labeling system do not wish to use the DNS architecture for name to address resolution, at all. However, they may wish to use the excellent transport mechanisms that IETF have defined over the years, including the latest version(s) of TLS. I come back to this below when considering the failure mode of communication to a URI. Additionally, they wish to protect the privacy of their users by having the DNS reject to resolve these names. We have a mechanism which reliably translates www.example.org into some on-the-wire byte representation and works. This does not need to change, or even be investigated. Here is what I believe the non-DNS resolution softwares want: 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) within the root zone as not a domain. i.e if anyone asks the answer for anything in or under that pTLD the answer is NXDOMAIN. 2. Iterative resolution software to also be aware of this, such that they have a permanent in cache response to hand out NXDOMAIN without bothering the root zone's resolvers (and exposing the query). 3. qname minimisation to be approved and implemented. In this case, if 2. is not achieved the exposure of the end user system is dramatically limited. All of the above is worst case usage from these softwares. Normal operation is that the DNS architecture does not even see these name resolutions happening -- they use whichever mechanism they have designed and implemented -- the end user is satisfied (assuming their mechanism works) and the DNS knows nothing. Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ When entered into the Tor browser, the DNS sees absolutely no traffic,
Re: [DNSOP] back to: Some distinctions and a request
If that is the case, that these folks don’t want to use the DNS name-address resolution at all, then there should be no objection to use of those labels in the DNS by folks who DO wish to use DNS for its intended purpose. If House Finch Feathers OY applies to ICANN for the .ONION TLD, there should be zero objection, since other use is outside the scope of the DNS. the use of a “reserved label” registry simply for “defensive” purposes is properly outside the scope of the IETF goal of defining and developing Internet Protocols. As to Andrews excellent attempt to disambiguate name space for domains and the DNS, I appreciate effort, but the facts are that overlaps occur in real life (see also: acronym overload) and the name space in question is the DNS view of the name space, not domain name space en-toto. (whee - hows that for a run-on sentence!) manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2July2015Thursday, at 9:04, Hugo Maxwell Connery h...@env.dtu.dk wrote: Hi Mr Lewis, and list, I believe that you are making a category error here. The key point is that the softwares that are using the domain name (dot separated network identifier) labeling system do not wish to use the DNS architecture for name to address resolution, at all. However, they may wish to use the excellent transport mechanisms that IETF have defined over the years, including the latest version(s) of TLS. I come back to this below when considering the failure mode of communication to a URI. Additionally, they wish to protect the privacy of their users by having the DNS reject to resolve these names. We have a mechanism which reliably translates www.example.org into some on-the-wire byte representation and works. This does not need to change, or even be investigated. Here is what I believe the non-DNS resolution softwares want: 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) within the root zone as not a domain. i.e if anyone asks the answer for anything in or under that pTLD the answer is NXDOMAIN. 2. Iterative resolution software to also be aware of this, such that they have a permanent in cache response to hand out NXDOMAIN without bothering the root zone's resolvers (and exposing the query). 3. qname minimisation to be approved and implemented. In this case, if 2. is not achieved the exposure of the end user system is dramatically limited. All of the above is worst case usage from these softwares. Normal operation is that the DNS architecture does not even see these name resolutions happening -- they use whichever mechanism they have designed and implemented -- the end user is satisfied (assuming their mechanism works) and the DNS knows nothing. Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ When entered into the Tor browser, the DNS sees absolutely no traffic, at all, irrespective of whether the domain name exists. E.g if asdfasdfasdfasdf.onion is not defined within the Tor network, still the DNS sees nothing. However, some configuration of a recently defined TLS transport is used (https). When opened with a regular browser, the use of the Tor network is exposed, as described above. The communication will fail, as the asdfasdfasdfasdf sub-domain is not registered (and hopefully not registerable). We are talking about *how* it fails, and reducing the leaking of information in that process. All of these on-list discussions are about point 1. above; Negative registration in the root zone via RFC6761. Steps 2 and 3 are, I expect, also on the agendas for these overlay networks, because they care about the privacy of their community. If point 2 could be universally achieved, points 1 and 3 are moot. But, that is never doing to happen, thus the current approach. Sincerely, Hugo Connery NB: I am not a member of the community for any of these networks, and I certainly dont speak on their behalf. I do use Tor regularly. From: Edward Lewis [edward.le...@icann.org] Sent: Thursday, 2 July 2015 14:51 To: Hugo Maxwell Connery; Andrew Sullivan; dnsop@ietf.org Subject: Re: [DNSOP] back to: Some distinctions and a request On 7/2/15, 6:02, DNSOP on behalf of Hugo Maxwell Connery dnsop-boun...@ietf.org on behalf of h...@env.dtu.dk wrote: Hi, I think that Andrew's effort to distinguish between a domain name and a DNS name is useful. It gives us some clear terminology to use to discuss domain names that wish to use a non-DNS name resolution method. Until this message, I wasn't clear on Andrew's distinction - we have been talking off-list for the past few days too. To me a domain name is: a sequence of bits that, when rendered in hex notation, can look like this: 0x03 0x61 0x62 0x63 0x07 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x00 That is what is sent over the wire, through ports and is
Re: [DNSOP] back to: Some distinctions and a request
On 7/2/15, 12:04, DNSOP on behalf of Hugo Maxwell Connery dnsop-boun...@ietf.org on behalf of h...@env.dtu.dk wrote: I believe that you are making a category error here. The key point is that the softwares that are using the domain name (dot separated network identifier) labeling system do not wish to use the DNS architecture for name to address resolution, at all. That's well understood. However, they may wish to use the excellent transport mechanisms that IETF have defined over the years, including the latest version(s) of TLS. I come back to this below when considering the failure mode of communication to a URI. Instead of transport which for me and others means things like TCP and UDP, I think you mean applications. If I understand correctly, Tor uses web browsers and URLs because the existing base does what Tor needs. Which is fine. Code reuse, etc. Additionally, they wish to protect the privacy of their users by having the DNS reject to resolve these names. That's not a way to protect privacy. Just asking a DNS server leaks some information. The DNS can't prevent anyone from asking, rejecting the query is too late. OTOH, as someone managing DNS operations, the queries don't leak enough of the right information (although they may leak the wrong information, with right/wrong a subjective call). We have a mechanism which reliably translates www.example.org into some on-the-wire byte representation and works. This does not need to change, or even be investigated. My point about on-the-wire was a tad bit obtuse. I was trying to explain what I thought a domain name was and relied upon the DNS protocol's version of what goes out the socket, through the port and out over the electromagnetic waves. I figure the DNS itself is unique in the formatting. When URLs go into the electromagnetic medium, I bet they are converted into something ascii-compatible or unicode encoded (I haven't checked). When X.509 certificates go out, the subjectAltName holding a domain name would be passed through ASN.1, then maybe a DER/BER/etc., and so on. If that's what is meant by a domain name, it's not what I was thinking. I wasn't trying to say all applications use the DNS format, just that when it comes to DNS names and domain names, I think of them as the same because I usually operate on the DNS wire format. Still, I'd like to see a common definition of what a domain name is in the context of domain name use in URLs, email addresses, X.509 subjectAltName and other places I'm not listing because I'm not thinking of them. Here is what I believe the non-DNS resolution softwares want: 1. A registration of the psuedo top level domain [pTLD] (e.g onion, gnu) within the root zone as not a domain. i.e if anyone asks the answer for anything in or under that pTLD the answer is NXDOMAIN. To some extent this is just a registration of the string in the root TLD. Just like registering a name that will work the impact is about the same up though registration. I thought about how to scale this and make this work seeing that there's a high application fee for positive registrations. I don't have a clear answer. An alt-TLD is a good partial solution, i.e., reserving one string the root is something I can see as possible but not a TLD per not a domain domain-looking namespace. E.g., One concern is confusability between names. Like, is example. and excyrillic-ample. the same thing? This has been an issue amongst commercial names. But what about .bit and .b1t? Neglecting money, cost, budget, there's still work to be done to avoid the ensuing operational issues that would likely follow. 2. Iterative resolution software to also be aware of this, such that they have a permanent in cache response to hand out NXDOMAIN without bothering the root zone's resolvers (and exposing the query). That's a lot of code to distribute. And existing code bases don't do this now. (Yes, the usual excuse for not innovating.) The reality is you can't stop someone from asking overnight. I could see such software consulting the special use domain name registry and dynamically deciding how to resolve the name. But that's generations (of code) off into the future. 3. qname minimisation to be approved and implemented. In this case, if 2. is not achieved the exposure of the end user system is dramatically limited. I see this as a non-sequitir. If one is not supposed to ask the DNS, then it doesn't matter. If one is leaking, this only means that some of the authoritative servers don't see the intended name, the recursive does. All of the above is worst case usage from these softwares. Normal operation is that the DNS architecture does not even see these name resolutions happening -- they use whichever mechanism they have designed and implemented -- the end user is satisfied (assuming their mechanism works) and the DNS knows nothing. Consider the URI https://asdfasdfasdfasdf.onion/my-holiday/ When entered into the Tor browser, the
Re: [DNSOP] back to: Some distinctions and a request
On 7/2/15, 13:34, DNSOP on behalf of Paul Vixie dnsop-boun...@ietf.org on behalf of p...@redbarn.org wrote: manning wrote: ... STRONGLY suggests that “domain-looking-string” is , in fact, a host that is identified using the Internet DNS. i agree with this interpretation, which means, it's the spec itself that's wrong, not hugo's interpretation of it. the internet people didn't love .UUCP addresses either but that didn't stop them from working. what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying we are the only thing you can use. At the risk of further annoying Andrews ... if there was a definition of domain name in contexts external to the DNS, that would be helpful. Plus, in each context, what are the escape rules, if needed? E.g., At one time, some funny guy tried to register ctrl-G as a TLD. (He knows who he is.) How would that be written in a URL? smime.p7s Description: S/MIME cryptographic signature ___ 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?
As an idea: some months ago dkg looked at hooking up unbound to an upstream resolver over TCP/TLS. It works, but it isn't ideal right now. Our findings: A) client and server together negotiate TLS 1.2 (that's good!) B) client doesn't appear to even try to validate the certificate C) client doesn't hold open connections, but rather does one query per connection. This is a tremendous amount of overhead. D) server selects TLS_RSA_WITH_AES_256_GCM_SHA384 even though client preferred TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. E) server offers a TLS session ticket each time, and client is not re-using the session ticket (or any other abbreviated handshake mechanism) that i can tell. unbound client config: forward-zone: name: . forward-addr: w.x.y.z@443 server: ssl-upstream: yes tcp-upstream: yes unbound server-config: interface: 0.0.0.0@443 interface: ::0@443 access-control: 0.0.0.0/0 allow ssl-port: 443 ssl-service-pem: /etc/unbound/unbound_server.pem ssl-service-key: /etc/unbound/unbound_server.key -tom On 1 July 2015 at 06:43, Dan York y...@isoc.org wrote: 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.org Allison Mankin, Verisign Labs 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=%0A (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.org +1-802-735-1624 Jabber: y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ ___ 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] Want to join the IETF 93 Hackathon to work on DNSSEC, DANE or DNS Privacy?
On Thu 2015-07-02 16:20:30 -0400, Tom Ritter wrote: As an idea: some months ago dkg looked at hooking up unbound to an upstream resolver over TCP/TLS. It works, but it isn't ideal right now. Our findings: A) client and server together negotiate TLS 1.2 (that's good!) B) client doesn't appear to even try to validate the certificate this is https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658 C) client doesn't hold open connections, but rather does one query per connection. This is a tremendous amount of overhead. D) server selects TLS_RSA_WITH_AES_256_GCM_SHA384 even though client preferred TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. E) server offers a TLS session ticket each time, and client is not re-using the session ticket (or any other abbreviated handshake mechanism) that i can tell. I hope to work on these issues during the hackathon. --dkg ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] back to: Some distinctions and a request
In message d1bafc60.ca8f%edward.le...@icann.org, Edward Lewis writes: On 7/2/15, 13:34, DNSOP on behalf of Paul Vixie dnsop-boun...@ietf.org on behalf of p...@redbarn.org wrote: manning wrote: ... STRONGLY suggests that =E2=80=9Cdomain-looking-string=E2=80=9D is , in fact, a host that is identified using the Internet DNS. i agree with this interpretation, which means, it's the spec itself that's wrong, not hugo's interpretation of it. the internet people didn't love .UUCP addresses either but that didn't stop them from working. what the internet should be doing is defining escape mechanisms for non-internet systems, rather than saying we are the only thing you can use. At the risk of further annoying Andrews ... if there was a definition of domain name in contexts external to the DNS, that would be helpful. Plus, in each context, what are the escape rules, if needed? E.g., At one time, some funny guy tried to register ctrl-G as a TLD. (He knows who he is.) How would that be written in a URL? In a domain name: \007 (RFC 1034 presentation encoding) In a host name: not possible as it is outside the allowable syntax. In a url it would depend upon the scheme. It would not be valid for http:, https: or mailto: to start with as all three are restricted to using hostnames. For those schemes where it is valid input %07. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
