[gtld-tech] [weirds] Search Engines Indexing RDAP Server Content

[Andrew Sullivan]

Hi,

In Francisco's defence, which is nowise to suggest I think
authenticated-and-differentiated access less important:

On Sat, Feb 06, 2016 at 12:22:48PM -0500, Ann Hammond via gtld-tech wrote:
> 1. Internationalization?  Ok, this is a stretch, but I'll give it to you.  But it's not like internationalized characters are disallowed by whois.  
> See, for example: whois -h whois.nic.xn--cg4bki nic.xn--cg4bki  There are others.
> 

Actually, it's not that i18n is disallowed or allowed by whois.  It's
that the whois protocol is _completely broken_ for this, because it
has no way to negotiate anything.  With whois, you connect on port 43,
send something, and get something vomited back.  It's probably ASCII,
but no promises.  That's the whole protocol.  That we are still using
whois even a little ought to embarrass us all.

> 2. Standardized query/response/errrors?  Again, a stretch.  301, 302, 404, 429... big deal.  Anyway, AWIP and CNRA have tried to do the first two.
> 

For machine-to-machine communication, this is a very big deal.  And
it's not only response codes.  You also get JSON objects as opposed to
structured text, so the entire result is machine parseable.  This was
squarely in our sights as a goal when we got the WEIRDS BoF going, and
I think it's a successful part of the RDAP design.  (Of course, this
very machine-parsability is what has so many of us worried that there
are unseen opportunities for data leakage without authenticated
differential access.  I think so far we've not demonstrated such a
leak, but that doesn't mean there isn't one.)

> 3. Ahem... extensibility?  Really?  Anyone wishing to support anything beyond the profile must undergo the dreaded RSEP, effectively muting this benefit. 
> 

The ability is certainly there, though I must concede that an ability
that can't be exercised for contractual reasons is perhaps somewhat
less useful.  Let us hope the PDP is successful!

> 4. HTTPS?  That's more important than authenticated/differentiated access?  Who is clamoring for this? Nobody!
> 

I am.  Lookups by innocent parties of registration data should no more
be trivially observable on the network than anything else.  Encrypt it
all.

> 5. Standardized bootstrapping?  New gTLDs must all support whois.nic.<tld>

To me, the bootstrapping's sort of a kludge anyway.  I would have
liked something more flexible and more in keeping with the
extensibility, for greater use down the tree, but I was in the rough
in the working group.

> 6. Standardized redirection for thin?  There are three thin registries: com, net, tv.  All provide the reference to registrar with the same key "whois server:"
> 

The point is that rwhois hasn't been that reliable, and RDAP solves this.

> 7. Flexibility to support various policies?  Okay, maybe someone at ICANN cares a lot about this, but few in the community care, especially given #3 above.  
> 

I cared quite a lot about this when WEIRDS was going, but the
IANA-based bootstrapping and the tight contractual control makes this
feature rather less interesting.
 
> I get the impression of ICANN internal pressure to force-feed the
> community RDAP to meet a date, rather than a desire to put forth a
> noteworthy advancement in RDDS.  Rather than dictate compliance with
> a profile that *seems* a product of ICANN's doing, rather than a
> grass-roots initiative, why doesn't ICANN invest effort in
> coordinating a solution to the obvious need for
> authenticated/differentiated access? 

I think Francisco's point is that ICANN is doing that co-ordination,
but under a PDP; and therefore changes can't be made now.  The
argument I made before, and still think is true, is that standing up a
mandatory profile for contracted parties that contained all the
protocol features would mean lower barriers to deployment later.  I
think ICANN's staff disagree.  I think informed people of good will can
disagree about this; and in any case I have learned that they have a
couple of regular consensus-policy deployment windows a year, which
means at least that we can have specific targets.  I'd still prefer my
approach, though :)

> And, if ICANN wishes to dictate something useful, federated authentication amongst registries would be a good start.  Better yet, ICANN could be the authenticator - THAT would be useful.
> 

I think Scott has already suggested using the federated-authentication
stuff in http(s) to do some auth-provider work.  ICANN's ability to
authenticate a large number of some kinds of client would indeed seem
to be a valuable contribution to that development/PoC effort.

Best regards,

A

-- 
Andrew Sullivan
Dyn
asullivan at dyn.com