Subject: [weirds] bootstrap draft

From: Marc Blanchet <[email-masked]>
Date: Tue, 4 Jun 2013 17:58:22 -0400

hello,
 please find an attempt to provide a solution to the "bootstrap" problem, i.e. finding the authoritative registration data server.  I don't pretend this is fully baked but enough to get a good discussion going. Please comment.

Regards, Marc.

================================

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Finding the Authoritative Registration Data (RDAP) Server
	Author(s)       : Marc Blanchet
	Filename        : draft-blanchet-weirds-bootstrap-00.txt
	Pages           : 7
	Date            : 2013-06-04

Abstract:
   This document specifies a method to find which Registration Data
   Access Protocol (RDAP) server is authoritative to answer queries for
   a requested scope, such as domain names, IP addresses or Autonomous
   System numbers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Jun 2013 11:03:31 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marc Blanchet
> Sent: Tuesday, June 04, 2013 5:58 PM
> To: [email-masked]
> Subject: [weirds] bootstrap draft
> 
> hello,
>  please find an attempt to provide a solution to the "bootstrap"
> problem, i.e. finding the authoritative registration data server.  I
> don't pretend this is fully baked but enough to get a good discussion
> going. Please comment.

Thanks for taking the time to write this, Marc. One suggestion at first glance: RFC 1035 doesn't use the term "NXDOMAIN". Would you consider "name error" or "response code 3" instead?

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jun 2013 07:16:27 -0700

On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott
<[email-masked]>wrote:

> Thanks for taking the time to write this, Marc. One suggestion at first
> glance: RFC 1035 doesn't use the term "NXDOMAIN". Would you consider "name
> error" or "response code 3" instead?
>
>
>
...or at least declare in a definitions section that NXDOMAIN is a symbolic
name for response code 3.  I've done that in other drafts.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Jun 2013 14:17:32 +0000

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Wednesday, June 05, 2013 10:16 AM
To: Hollenbeck, Scott
Cc: Marc Blanchet; [email-masked]
Subject: Re: [weirds] bootstrap draft

On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Marc Blanchet
> To: [email-masked]<mailto:[email-masked]>

...or at least declare in a definitions section that NXDOMAIN is a symbolic name for response code 3.  I've done that in other drafts.
Yup, that could work, too.

Scott

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 5 Jun 2013 10:22:07 -0400

Le 2013-06-05 à 10:17, "Hollenbeck, Scott" <[email-masked]> a écrit :

> On Wed, Jun 5, 2013 at 4:03 AM, Hollenbeck, Scott <[email-masked]> wrote:
ok. thanks. done in local copy.

Marc.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 05 Jun 2013 11:24:16 -0300

Marc,

thanks for writing this down. I personally favor the DNS approach (was
one of the possibilities listed early on, before we decided
bootstrapping was out of scope).

Regarding the doc itself, I think it works well for ipv4 and ipv6
addresses, but I'm not sure how it works for autnums since the ASN
number space (and thus its registry) is flat and not hierarchical like
the ipv4/ipv6 spaces.

The children of ip4.rdap.arpa / ip6.rdap.arpa can be sub-delegated in
the same way as the reverse tree is. However, in the case of ASNs, there
isn't an equivalent approach. You mention management by a single entity,
but I believe that the strength of the DNS approach is the ability to
delegate. Maybe we can come up with such an idea for autnum.

Further comments:

- The document proposes clients should query the rdap.arpa tree for
A/AAAA records but doesn't specify how to construct a URL for the actual
HTTP request.

- In the case of names it does suggest a way to construct the resulting
URL, but IMO, the explanation is not clear enough. Also, while I don't
have a problem with the 'static' way the URL is constructed, others may.
I think at least mentioning the issue and explaining why the decision to
go static is needed.

Other questions (I don't have an answer for them, and they don't mean
criticism, they just pop out of my mind):

- Why query for A/AAAA ? Why not query, for example, for TXT and put the
RDAP URLs in TXT records ? As another possibility someone (I think it
was Andy) brought up the NAPTR records.

- Why a different tree for ip4 / ip6 ? The same A/AAAA/TXTs could be put
in the reverse tree that's already there and, in most cases, already
signed with DNSSEC.

- The most discussed weakness of the DNS approach in the past has been
the issue with javascript-only clients which cannot make arbitrary DNS
queries. Some ideas were discussed, including the possibility of
providing 'helper' services. Maybe we can add that discussion in this doc.

Thanks again!

~Carlos

On 6/4/13 6:58 PM, Marc Blanchet wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Jun 2013 14:49:47 +0000

>A/AAAA records but doesn't specify how to construct a URL for the actual

This draft seems to be written from the standpoint that RDAP clients will
have good DNS libraries. If that is the assumption, I think it is a bad
plan (and a topic we have discussed before).

If that is not the case, then showing how HTTP URLs will be constructed
will be necessary.

Additionally, guidance that both A and AAAA queries would lead a reader to
believe that an RDAP client has a DNS facility that allows it, whereas
most RDAP clients will be built onto of HTTP libraries.

>was Andy) brought up the NAPTR records.

PLEASE NO! Let's not do DNS manipulation beyond what can be done in an
HTTP URL. I also fear any DNS TXT debate.

For the record, my NicInfo client does bootstrapping for IPv4, IPv6, and
ASNs without any of this machinery. I simply grabbed the IANA XML files.
Given the redirect model that the RIRs can setup where we redirect to the
appropriate RIR if the query went to the wrong server (needed for ERX
anyway), this is good enough.

Domains are a bit different.

-andy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 05 Jun 2013 12:11:56 -0300

Hey,
> On 6/5/13 10:24 AM, "Carlos M. Martinez" <[email-masked]> wrote:

... snip...

> HTTP URL. I also fear any DNS TXT debate.
Ha! Sorry if it wasn't you :D
> anyway), this is good enough.
My redirector-only implementation does the same. Works well enough, but
it still does not provide a complete solution as the URLs can only be
constructed by having researched the base URLs for each provider beforehand.

~Carlos

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Jun 2013 17:58:06 +0000

>constructed by having researched the base URLs for each provider

Since this information does not change too much, a "works well enough"
implementation is all we need.

What's wrong with the IANA keeping a registry of domain registry operators
to RDAP base URLs? Since the IANA keeps its registries in XML, a client
can just go fetch that every so often (every 6 months or so) and update
its map. And that strategy is already available for IP addresses and ASNs.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Wed, 05 Jun 2013 15:01:53 -0300

Andy,

	That could work.

	It could be in addition to redirects or instead of.

Regards,
as

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 5 Jun 2013 18:09:06 +0000

> Behalf Of Andy Newton
> Sent: Wednesday, June 05, 2013 1:58 PM
> To: Carlos M. Martinez
> Cc: [email-masked]

Simple and consistent with existing practice? That takes all the fun out of over-engineering a solution!

Seriously, though, if the IANA registry map is already being used to solve a similar problem - and has been demonstrated to work - there's a lot to be said for reusing existing technology.

Scott

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 5 Jun 2013 14:16:42 -0400

> its map. And that strategy is already available for IP addresses and ASNs.

ok. I think there are pros and cons for each approach. I'm half way done writing a separate draft on the "exclusive" use of IANA registries to see where it goes and will publish it tonight or tomorrow. Then, we can discuss and compare.  I think that topic warrants some discussion time during Berlin...

While bootstrapping was not clearly in scope at the beginning, I think it is pretty important to get it done. We don't want various implementations doing different things as we have seen just here and behave differently and having different answers. 

Marc.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 05 Jun 2013 15:33:32 -0300

Adding a column to the ipv4, ipv6 and asn registries listing 'RDAP base
URL' for each allocation registrationi would work ?

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 05 Jun 2013 15:35:53 -0300

Sorry I hit enter to quickly. The issue of bootstrapping for names
remains though.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 05 Jun 2013 15:37:07 -0300

I'll add my experience doing that to the redirects draft (if the WG
agrees), Andy you can chip in if you want. Having this experience
documented may be a good thing.

regards

~Carlos

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 5 Jun 2013 14:41:06 -0400

An IANA map seems a lot simpler than a full reverse DNS approach.

Its not too hard to write code in a client to update and store its IANA map
regularly.

An RDAP redirector should certainly do automated frequent updates, say
every night. It then provides a backup for clients who don't.

In addition, registry operators who change their RDAP urls in IANA should
keep their old service operating for a reasonable length of time so clients
don't fail.

-Ernie

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Jun 2013 12:04:13 -0700

On Wed, Jun 5, 2013 at 7:16 AM, Murray S. Kucherawy <[email-masked]>wrote:

> ...or at least declare in a definitions section that NXDOMAIN is a
> symbolic name for response code 3.  I've done that in other drafts.
>
>
>
>
...or reference RFC2308, which defines it.

-MSK

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 13 Jun 2013 16:04:15 +0200

Another note on this solution... (not sure if already mentioned)

there's no way of specifying the scheme in this solution. So, suppose
one wants to implement confidentiality, the only solution is to redirect
to an ssl host.

Either to the same host
	https://com.domain.rdap.arpa/domain/example.com
or to another
	https://rdap.com/domain/example.com

Issues:
[1] yet another redirect
[2] in the first case: not sure if one can request ssl certificates for
arpa domains
[3] in both cases: vulnerable to a mitm: attacker captures first
(non-ssl) request and redirects to bogus server (doing evil capturing stuff)

Another issue not related to redirects: in case the client 'knows' it
should authenticate to that particular rdap server, credentials are sent
in clear

Best regards,

Pieter

-- 
*Pieter Vandepitte*
*Software Engineer*
+32 16 29 89 27
*www.dnsbelgium.be* <http://www.dnsbelgium.be/>

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 13 Jun 2013 14:27:23 -0400

A DNS solution based on A and CNAME records doesn't fully meet the RDAP 
requirement. It provides an IP address, which is not the same as a url.

A provider may want to use the following scheme to host RDAP services 
for multiple TLDs on one server:
rdap.info/tld1/
rdap.info/tld2/

In addition, there might be a requirement to support earlier versions of 
the protocol (if RDAP advances beyond 1.0) as
rdap.info/tld1/1.0/
rdap.info/tld2/1.0/

All of these can be hosted on a single server with one IP address, using 
Virtual Hosting to direct each url to the right configuration. A DNS 
solution that only provides an IP address and not the url does not work.

TXT records seem to be the only fit that can provide a simple url and 
http vs https access (sorry to bring this up, but I missed implied 
earlier discussions of TXT records).

-Ernie

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 13 Jun 2013 22:20:26 +0200

Ernie,

I understand the concepts of virtual hosts and ip addresses, but  as I 
understand from the first proposal, a client should lookup the ip 
address starting from example.com.rdap.arpa to com.rdap.arpa to find 
the ip address of the server and then send a http (not https) request 
with the name being looked up, as the host http header.

I just wanted to emphasize the additional security issues (besides 
other issues) involved with that solution (and we should also do the 
same exercise for other solutions)

I totally agree with you that a DNS IP address lookup is not the the 
way to go, but I'm not (yet) convinced that TXT is the answer. The main 
issue with the TXT record is the same as NAPTR: in-the-browser 
javascript clients can't yet perform TXT lookups. This was a non-issue 
for me, but not for everyone here (which i respect)

A single point of failure rdap.org solution (who will operate it) is 
neither ideal (but i admit, simple for clients), especially when 
considering https to mitigate mitm attacks, this could cause a lot of 
traffic.

The distributed xml file (or preferrably json) reminds me of an era 
when hosts files were ftp-ed, but i think that's the reason why dns was 
invented, so that's why my personal favorite is also some dns-like 
solution. Nevertheless, it's a simple and effective solution (and works 
for javascript in-the-browser clients). The file could become huge, 
especially with the gTLDs, but gzip and browser caching come to the 
rescue here.

I have been thinking of other solutions, alas, no inspiration :-)

Pieter

On Thu 13 Jun 2013 08:27:23 PM CEST, Ernie Dainow wrote:
> A DNS solution based on A and CNAME records doesn't fully meet the
> RDAP requirement. It provides an IP address, which is not the same as
> a url.
>
> In addition, there might be a requirement to support earlier versions
> of the protocol (if RDAP advances beyond 1.0) as
> rdap.info/tld1/1.0/
> rdap.info/tld2/1.0/
>
> All of these can be hosted on a single server with one IP address,
> using Virtual Hosting to direct each url to the right configuration. A
> DNS solution that only provides an IP address and not the url does not
> work.
>

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2013 22:58:00 -0000

>one wants to implement confidentiality, the only solution is to redirect

You hard wire the scheme to be https on port 443.  For the DNS lookups,
DNSSEC is recommended where available.  Problem solved.

>[2] in the first case: not sure if one can request ssl certificates for

There's nothing technically different about arpa. than any other TLD.
Of course you can.  

For that matter, self-signed certificates are quite adequate to
protect the channel, and if you want host verification, use DANE.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Jun 2013 23:17:37 -0000

It's important to keep in mind that the point of a bootstrap is to get
a client going as quickly as possible.  There will probably be no more
than 1000 different RDAP servers, and hundreds of thousands of RDAP
clients.

So any time there's a tradeoff between making the client more complex
and making the server more complex, the correct answer is to make
the client simple and the server complex, unless there is a really,
really compelling reason to the contrary.

>for multiple TLDs on one server:

What is the functional benefit of requriring that every client in the
world support arbitrary URLs in a bootstrap?

Surely anyone competent to run a TLD is able to master http virtual
hosting and put the information on https://tld1.domain.rdap.arpa/ and
https://tld2.domain.rdap.arpa/.  In this case, the only difference at
the server is a few lines in the server config file and perhaps an
extra SSL certificate. Same server, same IP addresses, same data.

If you really like your rdap.info names, you can redirect from your
rdap.arpa URLs, but I see no benefit from doing so.

R's,
John

---

From: Pieter Vandepitte <[email-masked]>
Date: Fri, 14 Jun 2013 07:16:58 +0200

Hi John

Comments inline

> DNSSEC is recommended where available.  Problem solved.

Me personal, i'm a https believer, so, great idea. not sure if we can
sell that to the rest of the community

> There's nothing technically different about arpa. than any other TLD.

Technically speaking, yes. But i don't know the current policies applied
by CA community. We will have to speak to them before we make a decision

> protect the channel, and if you want host verification, use DANE.

DANE isn't currently supported in most browsers (in none so far i
think). Second, it's a very bad idea to have self signed certificates.
So a client now has to have a trust store with thousands of self signed
certificates? Perhaps distributed in an XML file ;-) No seriously, this
is not the way you want to go. Moreover, a javascript in-the-browser
client is a requirement for some people here... Will people have to
install self-signed certificates in the browser?

Best regards

Pieter

---

From: "John R Levine" <[email-masked]>
Date: 14 Jun 2013 08:09:57 -0400

> sell that to the rest of the community

Unless someone offers a compelling reason that they cannot support https, 
I think we're OK there.

> think). Second, it's a very bad idea to have self signed certificates.

No, it's not.

As I said in the message you were responding to, self-signed certs handle 
the issue of snooping on the http traffic.  If you want to authenticate 
the server, either you get a CA signed cert (which I really don't think is 
a big deal) or you nag your client provider to get with the program and 
implement DANE.

John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Pieter Vandepitte <[email-masked]>
Date: Mon, 17 Jun 2013 09:37:34 +0200

Hi John,

I 100% agree with you that DANE could provide a solution. But as i
mentioned in a previous post, it isn't supported by browsers and it will
take many years to be widely deployed, so it isn't a solution for those
who want to write clients in-the-browser.

Second, I feel some resistance to implement NAPTR in the clients because
of complexity, but to be honest, I don't see any difference in
complexity with DANE. So, this would disprove the argument that the
A-record solution is a much simpler solution.

Anyway, as I understand from you, CA's currently don't have business
rules on the supported tld's, so anything above should be theoretical

kr,

Pieter

On 06/14/2013 02:09 PM, John R Levine wrote:
> Unless someone offers a compelling reason that they cannot support
> https, I think we're OK there.
> 
> As I said in the message you were responding to, self-signed certs
> handle the issue of snooping on the http traffic.  If you want to
> authenticate the server, either you get a CA signed cert (which I really
> don't think is a big deal) or you nag your client provider to get with
> the program and implement DANE.
>

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 25 Jun 2013 15:36:32 -0400

While the DNS bootstrap proposal for domain names is a very nice, even 
elegant solution for the client, I had some concerns about the 
limitations: DNS mapping versus url mapping and https required for all 
RDAP servers. In a review with our operations people, they have no 
problem with DNS mapping; it can provide sufficient configuration 
flexibility via virtual hosting, if arpa name registration can be done 
with a CNAME (which has been assumed in some discussions but should 
explicitly be specified in the bootstrap draft).

However, there is a strong objection to requiring HTTPS if the server is 
only providing public data. In their experience, there is no graceful 
way to make certificates work without spending a lot of unnecessary 
money (self-signed certs are out, DANE depends on DNSSEC in the resolver 
and both are too far off in the future for widespread use).

Is there any feasible way to specify either http or https or both with 
the DNS bootstrap approach?

-Ernie

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 25 Jun 2013 15:52:06 -0400

Le 2013-06-25 à 15:36, Ernie Dainow <[email-masked]> a écrit :

> While the DNS bootstrap proposal for domain names is a very nice, even elegant solution for the client, I had some concerns about the limitations: DNS mapping versus url mapping and https required for all RDAP servers.

I knew when I wrote it...

I guess you are talking about domain names usage (compared to address registries). correct?

> In a review with our operations people, they have no problem with DNS mapping; it can provide sufficient configuration flexibility via virtual hosting, if arpa name registration can be done with a CNAME (which has been assumed in some discussions but should explicitly be specified in the bootstrap draft).

to my knowledge, CNAME and wildcards have been subject to issues in implementations, which brought RFC4592. 

> 
> However, there is a strong objection to requiring HTTPS if the server is only providing public data. In their experience, there is no graceful way to make certificates work without spending a lot of unnecessary money (self-signed certs are out, DANE depends on DNSSEC in the resolver and both are too far off in the future for widespread use).
> 
> Is there any feasible way to specify either http or https or both with the DNS bootstrap approach?

one way I was thinking about was to specify it at the http redirect level: i.e. default is http, but operator can do http redirect to https, when desired.  However, this method has his drawbacks.

Marc.

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2013 20:26:11 -0000

>and both are too far off in the future for widespread use).

You can get perfectly good certs from Geotrust or Comodo for $9/yr.
Or certs that are almost as good (98% rather than 99% coverage or
something like that) for free from Startcom.

Could you be more specific about what "a lot of unnecessary money"
means?  The only thing I can think of that might be an issue is
getting a cert for <tld>.rdap.arpa, which would require some help from
IANA to assure the cert signer that it's OK to issue a cert for that
name, but that seems like a one time issue that won't take a lot of
time or money.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2013 20:27:37 -0000

>to my knowledge, CNAME and wildcards have been subject to issues in implementations, which brought

Can we agree that the domain bootstrap is just per TLD, with no
wildcards?  The extra facility provided by wildcards is pretty minor,
and the extra hassle appears significant.

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 26 Jun 2013 14:21:30 -0400

> name, but that seems like a one time issue that won't take a lot of
It looks like we could use some of the inexpensive certs for RDAP but it 
still doesn't seem like the best solution to require https for public 
data. We would much prefer to see http as the default with server side 
rewrite/redirect to https if required (as noted by Marc).

Based on the data defined in current drafts, most RDAP queries will be 
for public data. The extra overhead, management and cost (even if not 
huge) should be born by the traffic that requires security, not by all 
RDAP servers.

-Ernie

---

From: "John R Levine" <[email-masked]>
Date: 26 Jun 2013 14:31:37 -0400

> Based on the data defined in current drafts, most RDAP queries will be for 
> public data. The extra overhead, management and cost (even if not huge) 
> should be born by the traffic that requires security, not by all RDAP 
> servers.

Remember that https provides channel security as well as confidentiality.

You want to use https when retrieving public data to ensure that you are 
talking to the server you think you are, and that what you received is 
what that server sent.

Imagine the fun when a bad guy does some DNS poisoning and pretends that 
his server is http://info.domain.rdap.arpa/.

Regards,

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 26 Jun 2013 14:34:54 -0400

Le 2013-06-26 à 14:31, "John R Levine" <[email-masked]> a écrit :

>> Based on the data defined in current drafts, most RDAP queries will be for public data. The extra overhead, management and cost (even if not huge) should be born by the traffic that requires security, not by all RDAP servers.
> 
> You want to use https when retrieving public data to ensure that you are talking to the server you think you are, and that what you received is what that server sent.

sure. but playing devil's advocate, we have been running whois without that security. I prefer better security, but the real question is if it is mandatory or not. Anyone who requested that as mandatory?

Marc.

> 
> Imagine the fun when a bad guy does some DNS poisoning and pretends that his server is http://info.domain.rdap.arpa/.
> 
> Regards,
> "I dropped the toothpaste", said Tom, crestfallenly._______________________________________________
> weirds mailing list
> [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 26 Jun 2013 14:56:17 -0400

> sure. but playing devil's advocate, we have been running whois without that security. I prefer better security, but the real question is if it is mandatory or not. Anyone who requested that as mand…

Seems to me that if it doesn't start as https, we have the usual downgrade 
attacks.

I realize that there was a time when the computational load of SSL was an 
issue, but these days when generic blade servers have eight-core 3GHz 
CPUs, is it any more?

Regards,

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 26 Jun 2013 17:22:28 -0400

On 2013-06-26 2:56 PM, John R Levine wrote:
>> sure. but playing devil's advocate, we have been running whois 
>> without that security. I prefer better security, but the real 
>> question is if it is mandatory or not. Anyone who requested that as 
>> mandatory?
>
> Seems to me that if it doesn't start as https, we have the usual 
> downgrade attacks.

Securing the channel is a good point. However, I believe http or https 
is a policy decision to be made by ICANN or the service provider. I 
understood the WEIRDS scope to be technical, not policy. As such we 
should not rule out http as a technical choice.

>
> I realize that there was a time when the computational load of SSL was 
> an issue, but these days when generic blade servers have eight-core 
> 3GHz CPUs, is it any more?
>
This may be partly true for a server. I think it may still be an issue 
for clients on smaller devices such as mobile phones.  The initial SSL 
handshake is particularly CPU intensive. With a REST architecture, each 
RDAP request is a new connection.

-Ernie

---

From: "John Levine" <[email-masked]>
Date: 26 Jun 2013 22:05:43 -0000

>should not rule out http as a technical choice.

As a technical fact, a CNAME or A or AAAA record does not include a
port number.  If we're going to use a DNS boostrap, we have to specify
one or the other.  Also, as a matter of good standards design, the
fewer gratuitous options in the spec, the more likely it is that
implementations will interoperate.

>RDAP request is a new connection.

I look at https sites on my tablet all the time.  CPUs are really fast
these days.  Or if someone is planning to do multiple WEIRDS queries
on her phone faster than she can read the results, I can't have a lot
of sympathy for complaints that it's too slow.

R's,
John

PS: Please can we not rehash the SRV argument.

---

From: Chris Wright <[email-masked]>
Date: Thu, 27 Jun 2013 10:26:55 +1000

Whilst I still don't agree with the reasons for discounting the SRV record IF we are to continue with the current proposed solution we could 'hack' it as follows to support the desired (by some) outcome:

<tld>-http.whatevernamespace.arpa	A	1.2.3.4
<tld>-https.whatevernamespace.arap	A	1.2.3.4

WERIDS clients should be required to lookup the <TLD>-https one first, and use it if found, otherwise they can look-up the http one.

Of course SRV is a much cleaner solution, but anyway.

Thanks

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
Sent: Thursday, 27 June 2013 8:06 AM
To: [email-masked]
Subject: Re: [weirds] bootstrap draft

>should not rule out http as a technical choice.

As a technical fact, a CNAME or A or AAAA record does not include a port number.  If we're going to use a DNS boostrap, we have to specify one or the other.  Also, as a matter of good standards design, the fewer gratuitous options in the spec, the more likely it is that implementations will interoperate.

>RDAP request is a new connection.

I look at https sites on my tablet all the time.  CPUs are really fast these days.  Or if someone is planning to do multiple WEIRDS queries on her phone faster than she can read the results, I can't have a lot of sympathy for complaints that it's too slow.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2013 01:38:33 -0000

><tld>-https.whatevernamespace.arap	A	1.2.3.4

Before we start coming up with clever kludges, let's find out if there
are registries for whom it would be a real problem to serve RDAP in
https. Everyone I know says that in the past the compute load for SSL
was an issue and people used special purpose accelerators, but these
days regular CPUs are plenty fast.

R's,
John

>Of course SRV is a much cleaner solution, but anyway.

Wouldn't help, we'd still have to decide whether to look up
_https._tcp.rdap or _http._tcp.rdap.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Jun 2013 12:05:05 +0200

Le 2013-06-27 00:05, John Levine a écrit :
> one or the other.

Repeating myself: why not specify that the client tries HTTPS first, 
then falls back to HTTP after e.g. a 5 second timeout?

(Maybe it's such a dumb idea that it's not worth replying to...)

Simon

---

From: Andy Newton <[email-masked]>
Date: Thu, 27 Jun 2013 11:49:33 +0000

>issue, but these days when generic blade servers have eight-core 3GHz

Server load was the argument given as to why we shouldn't be doing the
simpler solution of having somebody (possibly IANA) run a root RDAP
redirection service.

Somewhere in this thread, it was pointed out that VeriSign gets 3k qps and
that would overwhelm most web servers (btw, ARIN has seen load higher than
that in the past). So I've taken the time to write a prototype of an RDAP
root redirection server. It reads the current IANA XML files and does
redirects for /ip, /domain (both forward and reverse), and /autnum.

Using one server class machine and two client machines, Jmeter tells me I
can push 10k qps (CPU is not the bottleneck, the NICs are and possibly
Jmeter itself). I would assume that if IANA were to run this they'd run 4
servers at a minimum (2 per site x 2 sites ). That's more than enough
headroom to handle the load.

There are multiple benefits to this solution:

1. It handles the HTTP vs HTTPS much more gracefully.
2. Client software is much, much simpler for bootstrapping.
3. Local roots may be setup using the IANA XML files (let's say AfriNIC or
CNNIC want to run a local server for their community because roundtripping
across satellites and ocean cables is latent).
4. And hey, we have code now!

For those interested, the code is in git:
git clone http://anon:[email-masked]/scm/RRR/code.git

-andy

---

From: Andy Newton <[email-masked]>
Date: Thu, 27 Jun 2013 11:57:08 +0000

>RDAP request is a new connection.

Expanding on Ernie's concern here: there are more reasons than the cost of
certs and server CPU as to why HTTPS is not always what a client wants.

First, clients have to be configured with the correct root certs. Some
will simply ignore unknown roots, but a lot of RESTful software will throw
warnings or worse, errors, if not configured with the proper set of roots.
This is a hassle when you don't care to be doing HTTPS and can generate
unwarranted help desk traffic. I know of this first hand.

Second, TLS is more than just a CPU issue. It also adds considerably to
the number of packets exchanged when comparing HTTPS to HTTP and thus adds
latency. This is not noticeable to a user with a web browser, but to
automation and batch queries it slows things down considerably.

Registries shouldn't be forced to support HTTPS if they don't see a need
to do it.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Thu, 27 Jun 2013 13:01:35 +0100

Andy
   
    You mean this registry:

http://www.iana.org/domains/root/db

    This:

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

Or both?

Regards,
as
On 6/27/13 12:49 PM, Andy Newton wrote:
>  It reads the current IANA XML files and does

---

From: Andy Newton <[email-masked]>
Date: Thu, 27 Jun 2013 12:44:13 +0000

Both, and the IANA Autonomous System XML registry file as well. If you
look at the code, you'll see them in there. We'd need to ask IANA to
modify these registries to add both HTTP and HTTPS RDAP base URLs for each
registry that wishes to supply them, but that's seems very doable.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Thu, 27 Jun 2013 13:56:09 +0100

Thanks Andy.

    I was a bit lazy to look at the code. :)

Regards.
as

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 27 Jun 2013 10:40:56 -0400

> simpler solution of having somebody (possibly IANA) run a root RDAP

There are other issues related to a central service. The more the central service do work, the more it is subject to being attacked, to being legally bound if it does not supply the data in time, etc...  

So the best is to have a design that does not require a central service, or the least central service possible, so that those issues do not come into play. 

Moreover, I don't know if the IETF can really specify a central service to be done by someone.  What we can do is ask IANA to have protocol registries or to run a dns zone file under .arpa. We already have that in place. Something else, well, it may be possible, but it would be a different story to sell.

My take is that we should design a solution which is pretty distributed by nature using the current set of possibilities and that solution does not preclude someone to run a central server if the community desires to run that (for example, the recent ICANN work). For the protocol, the client and servers delivering the data, the specification should support that possibility, but not specify/mandate it.  I have some wording about this in the next rev of the draft coming soon. Hope this will get some concensus... ;-)

Marc.

---

From: Andy Newton <[email-masked]>
Date: Thu, 27 Jun 2013 17:50:35 +0000

On 6/27/13 10:40 AM, "Marc Blanchet" <[email-masked]> wrote:

>
>There are other issues related to a central service. The more the central
>service do work, the more it is subject to being attacked, to being
>legally bound if it does not supply the data in time, etc...
>
>So the best is to have a design that does not require a central service,
>or the least central service possible, so that those issues do not come
>into play.

This issue also apply to DNS, so I'm not sure how what I have proposed is
any different in this regard.

> 
>
>Moreover, I don't know if the IETF can really specify a central service
>to be done by someone.  What we can do is ask IANA to have protocol
>registries or to run a dns zone file under .arpa. We already have that in
>place. Something else, well, it may be possible, but it would be a
>different story to sell.

The IANA will be standing up an RPKI repository in the future. So asking
them is certainly possible. But as I've noted, it doesn't have to be IANA.
It could be ICANN or it could be any registry operator working in the
interest of their community.

Overall, these are squishy layer 9 issues which should not outweigh the
technical benefits this proposal provides.

-andy

---

From: "John Levine" <[email-masked]>
Date: 27 Jun 2013 18:15:53 -0000

>(Maybe it's such a dumb idea that it's not worth replying to...)

Please look up "downgrade attack".

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 27 Jun 2013 14:19:27 -0400

> any different in this regard.

don't agree. DNS is already super distributed, starting with the root servers. Moreover, the DNS udp paquets are much lightweight then an http request/response.

> It could be ICANN

well, currently IANA is a division of ICANN, so...

> or it could be any registry operator working in the

well, I don't think we can completly forget them. The IETF can not impose someone to run a central service.

Marc.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Jun 2013 20:22:13 +0200

> Please look up "downgrade attack".

?

If the HTTPS attempt works, then you know it's secure.

Otherwise, then you can't. Don't trust the data if you don't want to.

I can imagine an attacker being somehow able to prevent the HTTPS 
attempt from working, forcing the victim to fallback to HTTP, but then 
there's nothing forcing the victim to trust the data obtained over HTTP. 
Just don't go to HTTP if you're not willing to.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "John R Levine" <[email-masked]>
Date: 27 Jun 2013 14:37:48 -0400

> I can imagine an attacker being somehow able to prevent the HTTPS attempt 
> from working, forcing the victim to fallback to HTTP, but then there's 
> nothing forcing the victim to trust the data obtained over HTTP. Just don't 
> go to HTTP if you're not willing to.

I don't think you'll find much sympathy for this nihilistic attitude in 
the security community.

The downgrade attack is that the bad guy hijacks the traffic via a routing 
or DNS or bogus web cache hack or something.  But the bad guy doesn't have 
an SSL certificate so he fails SSL attempts and the victims use his fake 
non-SSL server.  Even though the real server uses SSL to protect all of 
its content, it doesn't work.

If you have a setup where some providers use SSL and some don't, you need 
a way to tell whether a site isn't offering SSL becuase it really doesn't, 
or because it's been hijacked.  This requires a way for the non-SSL sites 
to publish an assertion that they don't use SSL, and to do so in a way 
that is as secure as SSL.  Everyone I know who's looked at this problem 
has ended up using SSL for everything, which is what I think RDAP should 
do.

The incremental cost of SSL is no longer very high, and the set of 
probiems it avoids is substantial.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 27 Jun 2013 14:46:48 -0400

> any different in this regard.

I'm with Marc here.  If all RDAP queries start with a redirect from the 
master server, that is a major change to the design.  With the DNS 
bootstrap, the client asks where the TLD server is and makes its own 
query.  If it makes another query of the same TLD, it gets the answer from 
the local DNS cache so the bootstrap server isn't involved, and all the 
boostrap server knows is that some DNS cache handled at least one query to 
that TLD.

If you have a bootstrap redirector, there's nothing to cache, so all the 
queries go through the bootstrap server and that server knows exactly what 
the queries are and who's making them.  At least for names, the contents 
of that query stream is extremely valuable to domain squatters, SEO, and 
other bits of the domain industry, a dismaying number of whom have a 
history of being what we might call ethically challenged.  So this central 
service would be a huge target for all sorts of attacks, some of which 
could be pretty subtle.

For example, a bad guy could use some sort of DNS or route poisoning to 
steal queries, then return the correct answers while logging the queries. 
Or he could return mostly correct answers, and lie about some in which he 
has particular interest.  For the numbers crowd, assume that the bad guy 
is using someone else's IP range and wants to make it look like it belongs 
to him.

I realize that any of these attacks could be aimed at any of the 
individual TLD or RIR servers, but it seems a lot to ask IANA to have to 
bear the risk of dealing with all of this.

Regards,

---

From: Andy Newton <[email-masked]>
Date: Fri, 28 Jun 2013 13:27:55 +0000

>boostrap server knows is that some DNS cache handled at least one query

This is a mischaracterization of what I proposed. Having IANA run a
"master" bootstrap server is only one possibility. In reality, with IANA
XML registry files ANYBODY can run a bootstrap server.

Given that we currently get domain queries for TLDs, we'll end up doing
this regardless of a DNS solution. As I said before, it is just as easy
for us to return a 302 as it is a 404 in these cases.

>service would be a huge target for all sorts of attacks, some of which

Caching does exist in HTTP, and my NicInfo RDAP client does caching. It's
actually easier to do the smart caching for RDAP with TLD domain queries
than with reverse DNS, IP, or autnum queries.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 28 Jun 2013 12:38:22 -0400

> XML registry files ANYBODY can run a bootstrap server.

Well, sure, but now we have the new problem of how to tell virtuous 
bootstrap servers from evil ones that will steal your queries and 
sometimes redirect you to fake servers that will return lies.  There have 
been plenty of helpful web WHOIS lookup pages that have done ugly stuff 
like frontrunning domains that people asked about (most notoriously at 
Network Solutions) so this is not a hypothetical issue.

> for us to return a 302 as it is a 404 in these cases.

We're lucky that ARIN is mostly virtuous.

>> If you have a bootstrap redirector, there's nothing to cache, ...
> Caching does exist in HTTP, and my NicInfo RDAP client does caching.

But can it cache anything but exact queries?  If I ask for 
/ip/152.148.255.255 and then /ip/152.149.0.0, does the cache tell you 
anything useful?

Regards,

---

From: Carlos Martinez <[email-masked]>
Date: Fri, 28 Jun 2013 13:27:52 -0400

Sent from my iPad

On 28/06/2013, at 12:38, "John R Levine" <[email-masked]> wrote:

> Well, sure, but now we have the new problem of how to tell virtuous bootstrap servers from evil ones that will steal your queries and sometimes redirect you to fake servers that will return lies.  There have been plenty of helpful web WHOIS lookup pages that have done ugly stuff like frontrunning domains that people asked about (most notoriously at Network Solutions) so this is not a hypothetical issue.

You pool the good ones under trusted domains like *.arpa. If there are others outside, you use them at your own risk.

Carlos

---

From: "John R Levine" <[email-masked]>
Date: 28 Jun 2013 13:41:29 -0400

> You pool the good ones under trusted domains like *.arpa. If there are others outside, you use them at your own risk.

Hmmn.  You might want to check with IANA and see how they feel about 
vetting the reliability of random bootstrap servers.

Regards,

---

From: Andy Newton <[email-masked]>
Date: Sat, 29 Jun 2013 11:39:47 +0000

On 6/28/13 1:41 PM, "John R Levine" <[email-masked]> wrote:

>>>sometimes redirect you to fake servers that will return lies.  There
>>>have been plenty of helpful web WHOIS lookup pages that have done ugly
>>>stuff like frontrunning domains that people asked about (most
>>>notoriously at Network Solutions) so this is not a hypothetical issue.
>>
>> You pool the good ones under trusted domains like *.arpa. If there are
>>others outside, you use them at your own risk.
>

John, DNS is not magic and has the same layer 9 bootstrap issues all other
technologies have. How does IANA know that VeriSign is VeriSign when they
sign up their .com CNAME in rdap.arpa? How does a client know that the
list of roots in their DNS hints file are the correct ones, or that the
list of CA roots in their key store are valid? These are issues that face
every bootstrapping system.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 29 Jun 2013 10:17:31 -0400

> sign up their .com CNAME in rdap.arpa?

The same way they know it's Verisign when they update the .com name 
servers in the root.  One of the reasons I want the DNS bootstrap at IANA 
is that they already know who the TLDs are and have a secure way to accept 
updates from them.

> How does a client know that the list of roots in their DNS hints file 
> are the correct ones, or that the list of CA roots in their key store 
> are valid? These are issues that face every bootstrapping system.

Of course, but we can at least try not to make them worse.  I think there 
is a meaningful difference between telling people to use bootstrap data 
that they can trace back to IANA, and telling them to use some random 
opaque forwarder.

Regards,