[ARIN-consult] Consultation on ACSP 2018.3

[David Farmer]

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
> 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/p
> articipate/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
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 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
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>
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180330/3cf4e963/attachment.html>