Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On Mon, Aug 10, 2015 at 07:25:23PM +, Alec Muffett wrote: Some Googling suggests that the http:// scheme is defined in RFC 2616, which - to summarise - again does not mandate DNS. I'm by no means an expert on the scheme, but I think following the references means that 2616 does in fact inherit certain DNS limitations, because RFC 2616 refers normatively to RFC 2396, which says this: host = hostname | IPv4address hostname = *( domainlabel . ) toplabel [ . ] […] Hostnames take the form described in Section 3 of [RFC1034] and Section 2.1 of [RFC1123]: a sequence of domain labels separated by ., each domain label starting and ending with an alphanumeric character and possibly also containing - characters. The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single . if it is necessary to distinguish between the complete domain name and any local domain. That gets us right back to the limitations in 1034 and 1123, alas. RFC 3986, which obsoletes 2396, makes this only marginally better because it seems to use the presence of dots as a hint that the DNS is what's in use (though it does not in fact mandate that and suggests that the rules are OS dependent). It moreover says 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. That's hardly encouraging. I don't know how any implementation actually works in this respect, but the does not mandate DNS, while strictly true, doesn't make the argument work quite as well as one wants. Experience suggests that expectations of the old-fashioned Preferred Syntax from STD13 is all over the place. Presumably, that's why people keep picking things that sure look like domain names as identifiers; but we don't get to have the advantages without all the built-in costs. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies
At Sat, 8 Aug 2015 10:19:34 -0400, Donald Eastlake d3e...@gmail.com wrote: - Section 4.1 In order to maintain the security properties of this protocol, a client MUST NOT use the same Client Cookie value for requests to all servers. Specifically what does this mean? Does this mean, for example, the client generates a different cookie value for a different server (identified by its IP address) and maintain the cookie values per server basis? [...] Actually, the wording in the draft doesn't seem that good. Perhaps it should be more like In order to provide minimal authentication, a client MUST send client COOKIEs that will usually be different for any two servers at different IP addresses. It basically looks good to me. One possible concern is that the term usually is vague/ambiguous especially when used in the context of a MUST. So, if I were an author I'd add a sentence like this at the risk of sounding too verbose: Specifically how to make them usually different is implementation dependent, but it should be generally good enough to use a good hash function with the server address being a part of its seed. - Section 4.2 In order to maintain the security properties of this protocol, a server MUST NOT use the same Server Cookie value for responses to all clients. I'm also not sure how I should interpret this. Can't we basically assume this condition is met because the server cookie contains (in some way) the request source address and client cookie? Of course, a naive implementation of how to contain them could lead to the same server cookie value regardless of the difference of these values, but if this sentence tries to avoid such naiveness, I'd make the point clearer. Can you suggest replacement text? You seem to understand what is being said. As above, it could be reworded as In order to provide minimal authentication, a server MUST send server COOKIEs that will usually be different for clients at any two different IP addresses or with different client COOKIEs. Same comment as the previous point applies. - Section 5.2.3 Servers MUST, at least occasionally, respond to such requests to inform the client of the correct Server Cookie. By saying occasionally, it could read (to me) as if it intends to mean maintaining per-client state. While a server implementation I don't know why you would think that. See below. could actually do that, I guess that's something that this draft wants to avoid to see. If so, perhaps something like randomly instead of occasionally may be a better choice. I don't think there is much difference between randomly and occasionally but randomly implies some attempt at an actual pseudo-random mechanism. Occasionally can be satisfied by a pseudo-random mechanism but also by some simple rule like responding to every tenth request or every Nth request for some reasonable N. Right, so randomly is just one way to implement occasionally and was too restrictive. And it's related to the other point: one other way to make it occasional is to keep a per-client counter and respond to every Nth request for that client or something. I wouldn't be surprised if some implementor develops this specification that way to meet this MUST, and I thought we wanted to avoid that to happen. So we might emphasize that in an additional sentence, e.g., However, servers MUST NOT maintain per-client state to implement that in order to prevent resource consumption attacks on that state. - Section 5.5 Clients and servers MUST NOT continue to use the same secret in new requests and responses for more than 36 days and SHOULD NOT continue to do so for more than 26 hours. Many clients rolling over their It would be helpful if the rationale (if any) of these constant values (36 days and 26 hours) is explained. The rational is cryptographic hygiene. The longer you use any secret, the higher the probability it has been compromised. The specific values are to be sure in one case that the secret will not be used for much more than a month and in the other case for not much more than a day. The numbers may seem a bit odd but are designed to allow for weekends and holidays and time changes for daylight savings time and the like. While I don't think these times should be any longer I'm not sure the precise value is that important. I didn't mean the rationale about the very specific number like 36 or 26. It was more about the sense of scale of these constants, e.g., not more than a month. But I'd leave it to you whether or how to update the text to address this point. - Section 5.5 When a server or client starts receiving an increased level of requests with bad server cookies or replies with bad client cookies, it would be reasonable for it to believe it is likely under attack and it should
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Hi Alec, You wrote: To address Edward’s implicit request for information - rather than to address his request for document pointers - I’d like to share that I sketched how onion addressing works in previous discussion at: https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html …and am happy to answer questions to the best of my ability, or punt in the right direction. Onion addresses may in future be 64 characters long, perhaps even 80, when new code rolls; the principles are likely invariant, however. Thanks for the pointer and for the additional information on the address name length. Reading through the highlights two issues that have been raised in the past with the description of the special use names registry. The first is the continuing problem distinguishing between names in the DNS (e.g. the .onion TLD) and names in some larger namespace which is not limited to the DNS. The second is the likelihood that names that are not in DNS may eventually cease to be parsed well by software which naively expects them to match the DNS world. I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here. It doesn't define what the larger namespace encompassing the DNS is or could be well, and it doesn't provide a way to note the continuing evolution of the non-DNS resolution processes. It does a fine job with .example since that's fundamentally just a reservation, but .onion is showing its warts. I understand the urgency of the .onion case, but I suspect that we're going to have to split it back out of the current registry once we have fixed the problems with the registry itself. I am wondering if there is a way forward here where we permit the registration in the existing registry, but with a note that it will likely move into either a different registry or an expanded registry in the future. regards, Ted ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01
On Fri, Aug 7, 2015 at 4:08 PM, Ralph Droms rdroms.i...@gmail.com wrote: Second try... On Jul 21, 2015, at 4:06 AM 7/21/15, Ralph Droms (rdroms) rdr...@cisco.com wrote: Hi - The dnssd chairs would like to get some reviews of draft-ietf-dnssd-mdns-dns-interop-01, On Interoperation of Labels Between mDNS and DNS, from dnsop participants. draft-ietf-dnssd-mdns-dns-interop-01 is currently in dnssd WG last call and last call comments will be discussed in the dnssd WG meeting this week. Please post your feedback to dnsop or send to Tim and myself. - Ralph I think I understand it, and it seems good to me. Minor NIT - I would like the LDH acronym expanded or possibly defined the first time it is used. I knew the rule but was unfamiliar with the acronym, requiring a search to figure it out. -- Bob Harold ___ 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
Hi Alec, On Mon, Aug 10, 2015 at 11:04 AM, Alec Muffett al...@fb.com wrote: Hi Ted, thanks for the feedback. I don’t see any question in the above which impinges upon the draft so much as being related to internal operations of IETF and/or DNSOP, but I’d like to reinforce that CA/B-Forum are apparently happy so long as “.onion” is part of the recognised global namespace. You are correct, it was not a question for the draft itself. The minutiae of which bucket *that* lives in is probably not an issue? (Tag: Mark Nottingham, Richard Barnes) I think the Internet community needs to understand that a reservation in the encompassing name space means that no gTLD with the same string will be permitted in the DNS and understand who has the right specify the process by which the names within .onion are minted and assigned. It strikes me that if labels “beneath” the .onion special domain name may in future exceed the bounds expected of DNS - but the root is acknowledged to have global legitimacy - then it’s all to the better that DNS software is aware of “.onion” and basically ignores it, which it the other intent of the draft. As you allude to below, it is not that DNS software must ignore it, it is a requirement that software that might presume it is within the DNS context will become aware of the correct context. In an e-mail elsewhere I recently noted: A scan of section 3.2.2 of *RFC3986 “Uniform Resource Identifier (URI): Generic Syntax”* - I won’t claim to have read the whole thing - seems quite open to the existence of [namespaces other than DNS being used in URIs]: *A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. The most common name registry mechanism is the Domain Name System (DNS).* *[...dns format description elided...]* *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. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. 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.* This is a little bit more complicated than the above suggests, because a specific URI scheme can describe in detail which elements of RFC3986 syntax are expected within it. See, for example, RFC 6068, Section 2 http://tools.ietf.org/html/rfc6068#page-3 for the syntax of the mailto: URI (which is fundamentally different from URI schemes which use path elements in the way HTTP does). RFC 7595 https://tools.ietf.org/html/rfc7595 has some additional detail in the context of registrations. In a previous attempt at tackling the deployment of Distributed Hash Table-based names, Vidya Narayanan and I described an overlay authority scoped to specific overlay networks rather than the DNS (see: https://www.ietf.org/archive/id/draft-hardie-p2psip-p2p-pointers-01.txt for details), but the presumption we worked from was that you were dealing with new URI schemes. In this case, I believe .onion names that intend to be carried in URI slots that would also carry non-.onion names will either have to confirm that the URI's scheme-specific part permits it or update the syntax to do so. Nothing appears in there about DNS’s (semantic) 63-character label lengths, instead the constraint defined is DNS “syntax” - arguably strings of alnumhyphen separated by dots - and an overall 255-character length limit. Next-generation Onion Address Syntax has not yet been agreed, but the current plans exist within this syntax-and-255-limit definition, eg: a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion # first label exceeds 63 characters, hypothetical illustration only Existing Onion-Address Syntax (facebookcorewwwi.onion) is completely within existing DNS’s apparent semantics as well as syntax. Of course, this is orthogonal to the matter of registries within registries which you raise above, but I feel it worth raising. I believe that it would be valuable to check the proposed syntax against the individual schemes' scheme-specific-parts as part of the deliberations. regards, Ted Hardie -a — Alec Muffett Security
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On Aug 10, 2015, at 9:50 AM, Ted Hardie ted.i...@gmail.com wrote: I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here. It doesn't define what the larger namespace encompassing the DNS is or could be well, and it doesn't provide a way to note the continuing evolution of the non-DNS resolution processes. It does a fine job with .example since that's fundamentally just a reservation, but .onion is showing its warts. I understand the urgency of the .onion case, but I suspect that we're going to have to split it back out of the current registry once we have fixed the problems with the registry itself. I am wondering if there is a way forward here where we permit the registration in the existing registry, but with a note that it will likely move into either a different registry or an expanded registry in the future. Hi Ted, thanks for the feedback. I don’t see any question in the above which impinges upon the draft so much as being related to internal operations of IETF and/or DNSOP, but I’d like to reinforce that CA/B-Forum are apparently happy so long as “.onion” is part of the recognised global namespace. The minutiae of which bucket that lives in is probably not an issue? (Tag: Mark Nottingham, Richard Barnes) It strikes me that if labels “beneath” the .onion special domain name may in future exceed the bounds expected of DNS - but the root is acknowledged to have global legitimacy - then it’s all to the better that DNS software is aware of “.onion” and basically ignores it, which it the other intent of the draft. In an e-mail elsewhere I recently noted: A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): Generic Syntax” - I won’t claim to have read the whole thing - seems quite open to the existence of [namespaces other than DNS being used in URIs]: A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. The most common name registry mechanism is the Domain Name System (DNS). [...dns format description elided...] 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. Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. 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. Nothing appears in there about DNS’s (semantic) 63-character label lengths, instead the constraint defined is DNS “syntax” - arguably strings of alnumhyphen separated by dots - and an overall 255-character length limit. Next-generation Onion Address Syntax has not yet been agreed, but the current plans exist within this syntax-and-255-limit definition, eg: a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion # first label exceeds 63 characters, hypothetical illustration only Existing Onion-Address Syntax (facebookcorewwwi.onion) is completely within existing DNS’s apparent semantics as well as syntax. Of course, this is orthogonal to the matter of registries within registries which you raise above, but I feel it worth raising. -a — Alec Muffett Security Infrastructure Facebook Engineering London 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 08/10/2015 01:50 PM, Ted Hardie wrote: It does a fine job with .example since that's fundamentally just a reservation, but .onion is showing its warts. Hi Ted, I fully agree with Alec, and do not understand how .onion would differ from .example in that case, especially since as we're speaking, onion names are fully compatible with DNS domain names, syntactically speaking. Can you elaborate on the difference you see, and why should we need to think forward to a non-existing set of future registries where onion names could end up at some point if at all? Regards, == hk ___ 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 10 Aug 2015, at 13:25, Alec Muffett wrote: So, by this analysis I think Onions in http (and by extension https) are fine. Not to mention, appropriate. :-) If the smiley means they're already deployed, so we don't get to talk about whether they're appropriate, then fine, but that's why a bunch of people are complaining about the precedent this sets. If the smiley means this is a good protocol design that other people should follow, then I'm not sure we have consensus on that. -- Joe Hildebrand ___ 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
Five years is not enough. Think in terms of 20 to 50 years. Oh, of course. I was thinking of five years as the review cycle for names that people might want to reconsider. Mark wrote: If .BELKIN is reserved then it is not available to *anyone* including Belkin. The simplist fix for .BELKIN is for the vendor to request registration of the name through ICANN. It becomes a expensive mea-culpa. The IETF should leave this to ICANN processes. It occurs to me that a lot of this would be less painful if the ICANN new TLD process were clearer about dealing with collisions with informal use. AGB section 2.2.1.3 is about the DNS stability review, but it says There is a very low probability that extended analysis will be necessary for a string that fully complies with the string requirements in subsection 2.2.1.3.2 of this module. where those requirements basically say it has to be a valid ASCII or IDN DNS label. For .BELKIN, the answer would depend on the details of the application, which is unlike any other new TLD string review I can think of. 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
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
On Aug 10, 2015, at 1:25 PM, Joe Hildebrand hil...@cursive.net wrote:
If the smiley means they're already deployed, so we don't get to talk about
whether they're appropriate, then fine, but that's why a bunch of people are
complaining about the precedent this sets. If the smiley means this is a
good protocol design that other people should follow, then I'm not sure we
have consensus on that.
I apologise that my personal opinion and cheery demeanour appears to be
extrapolatable into a couple of contrasting strategic positional statements.
To put my personal opinion at greater and more clear length:
In the context of URI schemes, accessing a Tor onion site (currently) over HTTP
or HTTPS is precisely *that* - a fetch of HTML or other content which a HTTP or
HTTPS request might typically be used to access - without the client software
needing to be adapted for Tor access at Layer 7.
Such a fetch is functionally just a vanilla HTTP/S over an “alternate
transport, the latter generally enabled by a SOCKS proxy or a content-aware VPN.
Such fetches currently work, have done so for several years, and have been used
by many, many thousands of users, possibly millions.
Similarly, ssh://user@someonionaddress.onion
ssh://user@someonionaddress.onion is equally an extant and functional SSH
request to someonionaddress.onion
Equally git://someonionaddress.onion/user/project-name.git
git://someonionaddress.onion/user/project-name.git would not immediately
strike me as needing to be forcibly changed to “onion-git://“
onion-git://%E2%80%9C simply because Git is invoked over an alternate”
transport with a “alternate” name resolution. It currently works, so why break
it?
From this observation, my personal opinion of “the proper scheme for an HTTP/S
fetch to an Onion address is something of a duck-test:
TEST: if a fetch looks like HTTP/S and quacks like HTTP/S, then I think that it
should likely be given a HTTP/S scheme.
Conversely: it’s arguable that schemes like “daap” or “rtsp” are also
“HTTP-based”, and that *they* have special schemes, so perhaps fetches from
Onion-addresses should “have special schemes” too?
I can sympathise with this argument. It makes logical sense.
I personally differentiate and resolve this argument in terms of intent, and in
terms of client and server-software.
“rtsp://” for instance is used for streaming, and requires magic, RTSP-specific
headers, and the frontend is something like VLC or iTunes, and the backend
requires a special streaming stack.
To me, this smells of specialism.
Equally: if iTunes incorporates a webview and fetches a bunch of web-content
for human consumption, it likely uses a HTTP/S scheme to do so, rather than a
specialist “ituneshttps://“ scheme.
This smells of specialist software trying to be a general-purpose browser.
So, given these conditions:
- if the intent is largely to provide HTML+CSS content to human beings,
- if the client software is most likely a well-known browser (tor browser =
firefox) operating in its normal mode
- …but not necessarily or exclusively a browser…
- and if the server software is something like Apache + {Wordpress, Drupal, a
bunch of static HTML}
…then under these conditions, again, I apply the duck test. I feel that such
fetches are HTTP/S and should have that scheme.
Hence why I feel that the extant, vanilla HTTP/S schemes are most appropriate
for fetching browser content from onion addresses.
The other matters, regarding domain name resolution and generic URI syntax, I
have already covered at some length.
- a
*aside: using VLC to RTSP to an Onion address will work just fine when SOCKS
(etc) is configured… etc...
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
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
In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230)
should have probably enumerated clearly which name registries were acceptable
for those schemes, so that the following language from RFC 7320 (a BCP) could
be invoked against any attempt by an app – Onion or anyone else -- to inject
their own unique brand of “specialness” into the interpretation of the
Authority component of their URIs:
Scheme definitions define the presence, format and semantics of an
authority component in URIs; all other specifications MUST NOT
constrain, or define the structure or the semantics for URI
authorities, unless they update the scheme registration itself.
7230 casually mentions DNS and “network host table” as name registries that can
potentially be used for “http” and/or “https”, but never implies that those 2
constitute the only members of the set.
If both injecting “specialness” into the URI, and updating the “https” scheme
itself, were viewed as unavailable or unappealing options, then Onion – and
anyone else who follows the same path – would be left with no other choice but
to define their own scheme.
- Kevin
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Alec Muffett
Sent: Monday, August 10, 2015 5:25 PM
To: Joe Hildebrand
Cc: Edward Lewis; Ted Hardie; i...@ietf.org; Richard Barnes; dnsop@ietf.org;
Mark Nottingham
Subject: Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion
Special-Use Domain Name) to Proposed Standard
On Aug 10, 2015, at 1:25 PM, Joe Hildebrand
hil...@cursive.netmailto:hil...@cursive.net wrote:
If the smiley means they're already deployed, so we don't get to talk about
whether they're appropriate, then fine, but that's why a bunch of people are
complaining about the precedent this sets. If the smiley means this is a good
protocol design that other people should follow, then I'm not sure we have
consensus on that.
I apologise that my personal opinion and cheery demeanour appears to be
extrapolatable into a couple of contrasting strategic positional statements.
To put my personal opinion at greater and more clear length:
In the context of URI schemes, accessing a Tor onion site (currently) over HTTP
or HTTPS is precisely *that* - a fetch of HTML or other content which a HTTP or
HTTPS request might typically be used to access - without the client software
needing to be adapted for Tor access at Layer 7.
Such a fetch is functionally just a vanilla HTTP/S over an “alternate
transport, the latter generally enabled by a SOCKS proxy or a content-aware VPN.
Such fetches currently work, have done so for several years, and have been used
by many, many thousands of users, possibly millions.
Similarly, ssh://user@someonionaddress.onion is equally an extant and
functional SSH request to someonionaddress.onion
Equally git://someonionaddress.onion/user/project-name.git would not
immediately strike me as needing to be forcibly changed to
“onion-git://“onion-git://%E2%80%9C simply because Git is invoked over an
alternate” transport with a “alternate” name resolution. It currently works,
so why break it?
From this observation, my personal opinion of “the proper scheme for an HTTP/S
fetch to an Onion address is something of a duck-test:
TEST: if a fetch looks like HTTP/S and quacks like HTTP/S, then I think that it
should likely be given a HTTP/S scheme.
Conversely: it’s arguable that schemes like “daap” or “rtsp” are also
“HTTP-based”, and that *they* have special schemes, so perhaps fetches from
Onion-addresses should “have special schemes” too?
I can sympathise with this argument. It makes logical sense.
I personally differentiate and resolve this argument in terms of intent, and in
terms of client and server-software.
“rtsp://” for instance is used for streaming, and requires magic, RTSP-specific
headers, and the frontend is something like VLC or iTunes, and the backend
requires a special streaming stack.
To me, this smells of specialism.
Equally: if iTunes incorporates a webview and fetches a bunch of web-content
for human consumption, it likely uses a HTTP/S scheme to do so, rather than a
specialist “ituneshttps://“ scheme.
This smells of specialist software trying to be a general-purpose browser.
So, given these conditions:
- if the intent is largely to provide HTML+CSS content to human beings,
- if the client software is most likely a well-known browser (tor browser =
firefox) operating in its normal mode
- …but not necessarily or exclusively a browser…
- and if the server software is something like Apache + {Wordpress, Drupal, a
bunch of static HTML}
…then under these conditions, again, I apply the duck test. I feel that such
fetches are HTTP/S and should have that scheme.
Hence why I feel that the extant, vanilla HTTP/S schemes
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Kevin, On 11 Aug 2015, at 6:54 am, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes, so that the following language from RFC 7320 (a BCP) could be invoked against any attempt by an app – Onion or anyone else -- to inject their own unique brand of “specialness” into the interpretation of the Authority component of their URIs: Scheme definitions define the presence, format and semantics of an authority component in URIs; all other specifications MUST NOT constrain, or define the structure or the semantics for URI authorities, unless they update the scheme registration itself. 7230 casually mentions DNS and “network host table” as name registries that can potentially be used for “http” and/or “https”, but never implies that those 2 constitute the only members of the set. If both injecting “specialness” into the URI, and updating the “https” scheme itself, were viewed as unavailable or unappealing options, then Onion – and anyone else who follows the same path – would be left with no other choice but to define their own scheme. I think that would be a bad outcome indeed. Viewing this as injecting specialness into the URI is counter to the clear examples that Alec just gave of non-HTTP-based (and, indeed, non-URI-based) uses of .onion. So, I can't imagine what end such restrictions would serve, except as a (fairly artificial) way to frustrate the registration of .onion. I'd also point out that such an approach might place procedural barriers in place of getting .onion or something similar recognised, it would not significantly hinder its deployment — as evidenced by .onion itself. Regards, -- Mark Nottingham https://www.mnot.net/ ___ 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
I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here. Agreed. It seems to me that there are two somewhat separate things going on here. One is the .ONION issue. It's a domain name string that has a coordinated use that is implemented outside the RFC 1034/1035 DNS. The other is the .BELKIN and .CORP issue. They're domain name strings that have no coordinated use, but there's enough uncoordinated use that there'd be a stability risk if a live TLD started answering queries. In both cases, one question is when we reserve the name, and the other equally important question is when we un-reserve the name. For all three, I think there's adequate evidence to reserve them now. The un-reserve criteria is different, and I expect would be different for any other name we reserved. For .onion, it's not out of the question that five or ten years from now we check in with the ToR project and they say oh, the whole reserved name thing was such a hassle that we switched to onion:// names and we don't use domain names at all. For .BELKIN, the problem was a lot of home routers shipped a decade ago. Eventually most of them will die and the problem will go away. Or if the Belkin company wanted a vanity domain, they presumably know what the routers did and could come up with a TLD that avoided sending unfortunate responses to the old queries. For .CORP, I gather the main usage was for intranet TLS certificates, but the public CAs have stopped signing them so they will probably mostly go away, too. The point of these examples is not that we need to solve any of those issues now, but that a useful reserved name registry needs to deal with the reality that most reservations need not be forever. R's, John ___ 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
Hi again, Ted! On Aug 10, 2015, at 11:42 AM, Ted Hardie ted.i...@gmail.com wrote: […] I think the Internet community needs to understand that a reservation in the encompassing name space means that no gTLD with the same string will be permitted in the DNS and understand who has the right specify the process by which the names within .onion are minted and assigned. I would agree, in fact I feel this was strongly thrashed-out in discussion of the draft. A scan of section 3.2.2 of RFC3986 “Uniform Resource Identifier (URI): Generic Syntax” […] 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. This is a little bit more complicated than the above suggests, because a specific URI scheme can describe in detail which elements of RFC3986 syntax are expected within it. See, for example, RFC 6068, Section 2 https://urldefense.proofpoint.com/v1/url?u=http://tools.ietf.org/html/rfc6068%23page-3k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0Am=oCCVXQHML7Wu9tLutu8gi0yjQy%2FYshsl6QPZDObXbt0%3D%0As=169bbca645c89ea6cb6b8e1f492f00233288a5afea42e886b71051a7e31cdb61 for the syntax of the mailto: URI (which is fundamentally different from URI schemes which use path elements in the way HTTP does). RFC 7595 https://urldefense.proofpoint.com/v1/url?u=https://tools.ietf.org/html/rfc7595k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0Am=oCCVXQHML7Wu9tLutu8gi0yjQy%2FYshsl6QPZDObXbt0%3D%0As=2902ce28be4aa8782a28349946b7aeba381329ac17f118c226111a2f7de618d1 has some additional detail in the context of registrations. Some Googling suggests that the http:// scheme is defined in RFC 2616, which - to summarise - again does not mandate DNS. - Section 3.2.2 defines the host-name part in abstract regards TCP connections: identified resource is located at the server listening for TCP connections on that port of that host - Section 3.2.3 discusses string comparisons - Section 15.3 discusses DNS spoofing and DNS caching, which is inapplicable - Sections 5.2 and 14.23 discuss the Host header, the latter most specifically: The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. …again without reference to DNS. Since the use of an Onion in a Host header would reflect the origin, I think this works. So, by this analysis I think Onions in http (and by extension https) are fine. Not to mention, appropriate. :-) In this case, I believe .onion names that intend to be carried in URI slots that would also carry non-.onion names will either have to confirm that the URI's scheme-specific part permits it or update the syntax to do so. Exactly. I believe that they do. I believe that it would be valuable to check the proposed syntax against the individual schemes' scheme-specific-parts as part of the deliberations. Where else would you suggest looking, please? -a — Alec Muffett Security Infrastructure Facebook Engineering London 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
Five years is not enough. Think in terms of 20 to 50 years. On Aug 10, 2015, at 3:10 PM, John Levine jo...@taugh.com wrote: I believe that the registry we have currently defined doesn't do a great job of capturing the actual needs here. Agreed. It seems to me that there are two somewhat separate things going on here. One is the .ONION issue. It's a domain name string that has a coordinated use that is implemented outside the RFC 1034/1035 DNS. The other is the .BELKIN and .CORP issue. They're domain name strings that have no coordinated use, but there's enough uncoordinated use that there'd be a stability risk if a live TLD started answering queries. In both cases, one question is when we reserve the name, and the other equally important question is when we un-reserve the name. For all three, I think there's adequate evidence to reserve them now. The un-reserve criteria is different, and I expect would be different for any other name we reserved. For .onion, it's not out of the question that five or ten years from now we check in with the ToR project and they say oh, the whole reserved name thing was such a hassle that we switched to onion:// names and we don't use domain names at all. For .BELKIN, the problem was a lot of home routers shipped a decade ago. Eventually most of them will die and the problem will go away. Or if the Belkin company wanted a vanity domain, they presumably know what the routers did and could come up with a TLD that avoided sending unfortunate responses to the old queries. For .CORP, I gather the main usage was for intranet TLS certificates, but the public CAs have stopped signing them so they will probably mostly go away, too. The point of these examples is not that we need to solve any of those issues now, but that a useful reserved name registry needs to deal with the reality that most reservations need not be forever. R's, John ___ 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] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
In message 20150810191030.13804.qm...@ary.lan, John Levine writes: I believe that the registry we have currently defined doesn't do a great j ob of capturing the actual needs here. Agreed. It seems to me that there are two somewhat separate things going on here. One is the .ONION issue. It's a domain name string that has a coordinated use that is implemented outside the RFC 1034/1035 DNS. The other is the .BELKIN and .CORP issue. They're domain name strings that have no coordinated use, but there's enough uncoordinated use that there'd be a stability risk if a live TLD started answering queries. In both cases, one question is when we reserve the name, and the other equall y important question is when we un-reserve the name. For all three, I think there's adequate evidence to reserve them now. The un-reserve criteria is different, and I expect would be different for any other name we reserved. For .onion, it's not out of the question that five or ten years from now we check in with the ToR project and they say oh, the whole reserved name thing was such a hassle that we switched to onion:// names and we don't use domain names at all. For .BELKIN, the problem was a lot of home routers shipped a decade ago. Eventually most of them will die and the problem will go away. Or if the Belkin company wanted a vanity domain, they presumably know what the routers did and could come up with a TLD that avoided sending unfortunate responses to the old queries. If .BELKIN is reserved then it is not available to *anyone* including Belkin. The simplist fix for .BELKIN is for the vendor to request registration of the name through ICANN. It becomes a expensive mea-culpa. The IETF should leave this to ICANN processes. For .CORP, I gather the main usage was for intranet TLS certificates, but the public CAs have stopped signing them so they will probably mostly go away, too. The point of these examples is not that we need to solve any of those issues now, but that a useful reserved name registry needs to deal with the reality that most reservations need not be forever. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard
Kevin, On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes, so that the following language from RFC 7320 (a BCP) could be invoked against any attempt by an app – Onion or anyone else -- to inject their own unique brand of “specialness” into the interpretation of the Authority component of their URIs To echo Mark’s rebuttal of this statement, I would like to ask what benefit would be served by doing so, please? Thanks, - alec — Alec Muffett Security Infrastructure Facebook Engineering London signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Gen-ART and OPS-Dir review of draft-ietf-dnsop-dns-terminology-03
Thank you for the careful review! Comments below, in an shortened form. On 10 Aug 2015, at 17:09, Black, David wrote: Major Issues: [BCP] Is BCP status appropriate for this draft? Based on earlier comments, we have chosen to change this to Informational for the next draft. [DownRef] idnits 2.13.02 found a number of obsolete references and downrefs. These are all probably ok, given the historical retrospective nature of this draft, but the authors should double-check them: ** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) ** Obsolete normative reference: RFC 1206 (Obsoleted by RFC 1325) ** Downref: Normative reference to an Informational RFC: RFC 6561 ** Downref: Normative reference to an Informational RFC: RFC 6781 ** Downref: Normative reference to an Informational RFC: RFC 6841 ** Downref: Normative reference to an Informational RFC: RFC 7344 I've tagged this as a major issue solely because I believe that Downrefs are supposed to be explicitly noted in the IETF Last Call announcement, and that does not appear to have occurred in this case. We did look carefully at all of these. When we do a -bis of this document (which is intended to be BCP), maybe the chairs and AD will remember the explicit notice in the IETF Last Call announcement. Or maybe there will be a tool that looks for this before IETF Last Call announcements can be made... Minor Issues: [A] Introduction - p.3 In this document, where the consensus definition is the same as the one in an RFC, that RFC is quoted. Where the consensus definition has changed somewhat, the RFC is mentioned but the new stand-alone definition is given. Should any RFCs be formally Updated when the latter sentence applies, or are any such actions being deliberately deferred to the revision of this document promised in the fourth paragraph of its Introduction? If the latter, please add a sentence to say so. As we said earlier, we intend to have this be Informational, with the -bis document being BCP and updating older RFCs as appropriate. That will be much harder than the current work. [B] 2. Names - p.4 Label: The identifier of an individual node in the sequence of nodes that comprise a fully-qualified domain name. Unless I've missed something fundamental, please change: sequence of nodes - sequence of identifiers You may have missed something fundamental, or just parsed the sentence wrong. The individual node is truly in a sequence of nodes. [C] 2. Names - p.5, end of Public suffix definition: One example of the difficulty of calling a domain a public suffix is that designation can change over time as the registration policy for the zone changes, such as the case of the .uk zone around the time this document is published. That calls for either an explanation or citation of a reference where further info can be found on this situation. This seems editorial, but RFCs are archival documents, and this sentence is likely to be lost on readers in some future decade. We are adding more in the next draft, as well as changing the example. [D] 8. General DNSSEC - p.16 DNSSEC-aware and DNSSEC-unaware: Section 2 of [RFC4033] defines many types of resolvers and validators, including non-validating security-aware stub resolver, non-validating stub resolver, security-aware name server, security-aware recursive name server, security-aware resolver, security-aware stub resolver, and security-oblivious 'anything'. (Note that the term validating resolver, which is used in some places in those documents, is nevertheless not defined in that section.) That doesn't seem to actually define anything. What do those two terms mean? Those terms are defined in RFC 4033, and that definition is not repeated here because it happens over a few sections. Nits/editorial comments: Introduction - p.3 Note that there is no single consistent definition of the DNS. It can be considered to be some combination of the following: a commonly-used naming scheme for objects on the Internet; a database representing the names and certain properties of these objects; an architecture providing distributed maintenance, resilience, and loose coherency for this database; and a simple query-response protocol (as mentioned below) implementing this architecture. a database representing - a distributed database representing Good, yes. 2. Names - p.5 Public suffix: A domain under which subdomains can be registered, and on which HTTP cookies ([RFC6265]) should not be set. There is no indication in a domain name whether or not it is a public suffix; that can only be determined by outside means. The IETF DBOUND Working Group [DBOUND] deals with issues with public suffixes. RFCs are archival documents - please rephrase so that this text does not assert the perpetual existence of the DBOUND WG - inserting At the time of publication of this document
