[ARIN-consult] Consultation on ACSP 2018.3

Mon Apr 2 09:00:30 EDT 2018

There’s been some great discussion on this topic.  I’d like to suggest the following approach:

*	No auto-redirection at this time
*	But stop redirecting https://whois.arin.net to http://whois.arin.net/ui/, rather redirect them to https://whois.arin.net/ui. If they chose to go to the secure site, being redirected to the insecure site does not seem like a good idea.
*	Make sure that all links from ARIN’s other sites to whois.arin.net are referring to the HTTPS one (that may already be the case, but I don’t know)
*	Enable HSTS for whois.arin.net – if a web browser hits it intentionally then just keep doing it automatically.
*	Provide some subtle feedback (perhaps an extra line/bar at the top of the page) to those web browsing the HTTP version of whois.arin.net to alert them that they are searching in the clear and provide a link to the secure version.
*	Develop a long-term goal to migrate programmatic access to HTTPS

Frank

From: ARIN-consult <arin-consult-bounces at arin.net> On Behalf Of David Farmer
Sent: Friday, March 30, 2018 12:07 PM
To: Rob Seastrom <rs at seastrom.com>
Cc: <arin-consult at arin.net> <arin-consult at arin.net>
Subject: Re: [ARIN-consult] Consultation on ACSP 2018.3

See inline;

On Thu, Mar 29, 2018 at 9:23 AM, Rob Seastrom <rs at seastrom.com <mailto:rs at seastrom.com> > wrote:

> On Mar 29, 2018, at 5:44 AM, Job Snijders <job at ntt.net <mailto:job at ntt.net> > wrote:
>
> On Wed, Mar 28, 2018 at 04:33:22PM -0500, David Farmer wrote:
>> On Wed, Mar 28, 2018 at 4:16 PM, ARIN <info at arin.net <mailto:info at arin.net> > wrote:
>>> ...
>>> Question:  Should ARIN automatically redirect user Whois queries made
>>> via "http" to "https"?
>>
>> No, ARIN should not automatically redirect Whois queries made via
>> "http" to "https". Insecure Whois queries made via "http", need to be
>> allowed.
>
> Do you have any supporting arguments for your statement?

That's a fair question and my answer to the question above was probably a little too terse.  I intended to not repeat what I had said in the thread regarding the original suggestion and I ended up proving just my answer insufficient justification for it. Rob summarizes my feelings on the subject well.  

More below;

Hi Job,

I suppose I wouldn't have any problems with automatic redirects for anything that had a user-agent that looked like a modern browser.

I did a cursory look and couldn't find the slide deck, but my recollection from a presentation by Mark Kosters is that there are a significant number of things hitting the REST interface that are not browsers; they may even outnumber the human visitors - and it's the same host, whois.arin.net <http://whois.arin.net> .

Neither you nor I has any idea how well those clients will handle redirects and https.  One would earnestly hope that by and large folks are using standard libraries that will magically do the right thing, yet repeated experiences with password hash dumps wherein a homemade (and cryptographically poor) KDF has been employed shows that the DIY spirit is alive and well and I would not expect it to be any different here.

So there's a balance of harms argument to be had: is forcibly encrypting traffic that has historically been of marginal privacy concern worth breaking client software in the field?  Bear in mind that if someone chooses to use https:// then things will be encrypted just fine; there is nothing forcing the client to be unencrypted when they'd rather be encrypted, and deploying HSTS will make modern browser users sticky to https://.

I submit that David has articulated the right balance to strike and that redirects are a poor idea.  If we advertise for some number of years that we're sunsetting non-https access to whois (if events haven't been overtaken by RDAP at that point), then I'll probably feel differently about this.

Note that I'm generally in favor of encryption.  In January 2015 I submitted an ACSP proposal asking for HSTS where practicable and in October 2015 I mentioned at the members' meeting that HSTS on the REST-Whois seemed to have been overlooked (see https://www.rwhois.net/vault/participate/meetings/reports/ARIN_36/mem_transcript.html ).  I'm just not a fan of intentionally breaking things, even if they're crappy software, without a lot of forethought and deliberate intent.

Upon reflection, and building on Rob's comments, I'm changing my answer, ARIN should adopt a goal of redirecting all "http" traffic to "https" for  <http://whois.arin.net/> whois.arin.net. However, I don't think "http" access to  <http://whois.arin.net/> whois.arin.net, especially programmatic access to the Whois REST API, should be precipitously terminated. Therefore a sufficiently generous sunset date needs to be given for the discontinuation of "http" access to  <http://whois.arin.net/> whois.arin.net and the redirecting all "http" traffic to "https", I'd say at least a year. However, the date for final discontinuation of "http" access should be driven by data about the amount of use of the "http" version of  <http://whois.arin.net/> whois.arin.net, and not some inflexible sunset date. On the other hand, I'm not saying access to the "http" version of  <http://whois.arin.net/> whois.arin.net needs to get to zero before it can be terminated either, but we need to understand and accept the potential damage caused by the event before it happens.

In the meantime providing HSTS policy and redirecting "http" traffic for most known browser user agents should begin ASAP.

Thanks

-- 

===============================================
David Farmer               Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu> 
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota   
2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815> 
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952> 
===============================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180402/406cd1ef/attachment.html>