[ARIN-consult] Consultation on ACSP 2018.3
bjones at vt.edu
Mon Apr 2 14:07:45 EDT 2018
+1 Frank's suggestions. They seem to be a reasonable step forward.
On Mon, Apr 2, 2018, 09:00 <frnkblk at iname.com> wrote:
> 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
> - 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
> *From:* ARIN-consult <arin-consult-bounces at arin.net> *On Behalf Of *David
> *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> wrote:
> > On Mar 29, 2018, at 5:44 AM, Job Snijders <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> 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.
> 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
> 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
> 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
> ). 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
> whois.arin.net. However, I don't think "http" access to 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
> 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 whois.arin.net, and not some inflexible sunset date. On the
> other hand, I'm not saying access to the "http" version of 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
> In the meantime providing HSTS policy and redirecting "http" traffic
> for most known browser user agents should begin ASAP.
> David Farmer Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the
> ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-consult