<div dir="auto"><div>+1 Frank's suggestions. They seem to be a reasonable step forward. </div><div dir="auto"><br></div><div dir="auto">Brian Jones <br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon, Apr 2, 2018, 09:00  <<a href="mailto:frnkblk@iname.com">frnkblk@iname.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-8405642608148365965WordSection1"><p class="MsoNormal">There’s been some great discussion on this topic.  I’d like to suggest the following approach:<u></u><u></u></p><ul style="margin-top:0in" type="disc"><li class="m_-8405642608148365965MsoListParagraph" style="margin-left:0in">No auto-redirection at this time<u></u><u></u></li><li class="m_-8405642608148365965MsoListParagraph" style="margin-left:0in">But stop redirecting <a href="https://whois.arin.net" target="_blank" rel="noreferrer">https://whois.arin.net</a> to <a href="http://whois.arin.net/ui/" target="_blank" rel="noreferrer">http://whois.arin.net/ui/</a>, rather redirect them to <a href="https://whois.arin.net/ui" target="_blank" rel="noreferrer">https://whois.arin.net/ui</a>. If they chose to go to the secure site, being redirected to the insecure site does not seem like a good idea.<u></u><u></u></li><li class="m_-8405642608148365965MsoListParagraph" style="margin-left:0in">Make sure that all links from ARIN’s other sites to <a href="http://whois.arin.net" target="_blank" rel="noreferrer">whois.arin.net</a> are referring to the HTTPS one (that may already be the case, but I don’t know)<u></u><u></u></li><li class="m_-8405642608148365965MsoListParagraph" style="margin-left:0in">Enable HSTS for <a href="http://whois.arin.net" target="_blank" rel="noreferrer">whois.arin.net</a> – if a web browser hits it intentionally then just keep doing it automatically.<u></u><u></u></li><li class="m_-8405642608148365965MsoListParagraph" style="margin-left:0in">Provide some subtle feedback (perhaps an extra line/bar at the top of the page) to those web browsing the HTTP version of <a href="http://whois.arin.net" target="_blank" rel="noreferrer">whois.arin.net</a> to alert them that they are searching in the clear and provide a link to the secure version.<u></u><u></u></li><li class="m_-8405642608148365965MsoListParagraph" style="margin-left:0in">Develop a long-term goal to migrate programmatic access to HTTPS<u></u><u></u></li></ul><p class="MsoNormal" style="margin-left:.25in"><u></u> <u></u></p><p class="MsoNormal">Frank<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><b>From:</b> ARIN-consult <<a href="mailto:arin-consult-bounces@arin.net" target="_blank" rel="noreferrer">arin-consult-bounces@arin.net</a>> <b>On Behalf Of </b>David Farmer<br><b>Sent:</b> Friday, March 30, 2018 12:07 PM<br><b>To:</b> Rob Seastrom <<a href="mailto:rs@seastrom.com" target="_blank" rel="noreferrer">rs@seastrom.com</a>><br><b>Cc:</b> <<a href="mailto:arin-consult@arin.net" target="_blank" rel="noreferrer">arin-consult@arin.net</a>> <<a href="mailto:arin-consult@arin.net" target="_blank" rel="noreferrer">arin-consult@arin.net</a>><br><b>Subject:</b> Re: [ARIN-consult] Consultation on ACSP 2018.3<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><br>See inline;<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Mar 29, 2018 at 9:23 AM, Rob Seastrom <<a href="mailto:rs@seastrom.com" target="_blank" rel="noreferrer">rs@seastrom.com</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal"><br>> On Mar 29, 2018, at 5:44 AM, Job Snijders <<a href="mailto:job@ntt.net" target="_blank" rel="noreferrer">job@ntt.net</a>> wrote:<br>><br>> On Wed, Mar 28, 2018 at 04:33:22PM -0500, David Farmer wrote:<br>>> On Wed, Mar 28, 2018 at 4:16 PM, ARIN <<a href="mailto:info@arin.net" target="_blank" rel="noreferrer">info@arin.net</a>> wrote:<br>>>> ...<br>>>> Question:  Should ARIN automatically redirect user Whois queries made<br>>>> via "http" to "https"?<br>>><br>>> No, ARIN should not automatically redirect Whois queries made via<br>>> "http" to "https". Insecure Whois queries made via "http", need to be<br>>> allowed.<br>><br>> Do you have any supporting arguments for your statement?<u></u><u></u></p></blockquote><p class="MsoNormal"><br>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.  <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">More below;<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">Hi Job,<br><br>I suppose I wouldn't have any problems with automatic redirects for anything that had a user-agent that looked like a modern browser.<br><br>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, <a href="http://whois.arin.net" target="_blank" rel="noreferrer">whois.arin.net</a>.<br><br>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.<br><br>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 <a rel="noreferrer">https://</a>.<br><br>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.<br><br>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 <a href="https://www.rwhois.net/vault/participate/meetings/reports/ARIN_36/mem_transcript.html" target="_blank" rel="noreferrer">https://www.rwhois.net/vault/participate/meetings/reports/ARIN_36/mem_transcript.html</a> ).  I'm just not a fan of intentionally breaking things, even if they're crappy software, without a lot of forethought and deliberate intent.<u></u><u></u></p></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><div><p class="MsoNormal" style="background:white"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#222222;background:white">Upon reflection, and building on Rob's comments, I'm changing my answer, ARIN should adopt a goal of redirecting all "<span class="m_-8405642608148365965gmail-gr">http</span>" traffic to "https" for <a href="http://whois.arin.net/" target="_blank" rel="noreferrer"><span style="color:#1155cc">whois.arin.net</span></a>. However, I don't think "<span class="m_-8405642608148365965gmail-gr">http</span>" access to <a href="http://whois.arin.net/" target="_blank" rel="noreferrer"><span style="color:#1155cc">whois.arin.net</span></a>, especially programmatic access to the Whois REST API, should be precipitously terminated. Therefore</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#222222"> a sufficiently generous sunset date needs to be given for the discontinuation of<span style="background:white"> "</span><span class="m_-8405642608148365965gmail-gr">http</span><span style="background:white">" access to </span><a href="http://whois.arin.net/" target="_blank" rel="noreferrer"><span style="color:#1155cc">whois.arin.net</span></a> and the <span style="background:white">redirecting all "<span class="m_-8405642608148365965gmail-gr">http</span>" traffic to "https", I'd say at least a year. However, the date for final discontinuation of "<span class="m_-8405642608148365965gmail-gr">http</span>" access should be driven by data about the amount of use of the "<span class="m_-8405642608148365965gmail-gr">http</span>" version of <a href="http://whois.arin.net/" target="_blank" rel="noreferrer"><span style="color:#1155cc">whois.arin.net</span></a>, and not some inflexible sunset date. On the other hand, I'm not saying access to the "<span class="m_-8405642608148365965gmail-gr">http</span>" version of <a href="http://whois.arin.net/" target="_blank" rel="noreferrer"><span style="color:#1155cc">whois.arin.net</span></a> 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.</span><u></u><u></u></span></p></div><div><p class="MsoNormal" style="background:white"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#222222"><u></u> <u></u></span></p></div><div><p class="MsoNormal" style="background:white"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#222222;background:white">In the meantime providing HSTS policy and redirecting "<span class="m_-8405642608148365965gmail-gr">http</span>" traffic for most known browser user agents should begin ASAP.</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:#222222"><u></u><u></u></span></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><p class="MsoNormal">===============================================<br>David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank" rel="noreferrer">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota   <br>2218 University Ave SE        Phone: <a href="tel:(612)%20626-0815" target="_blank" rel="noreferrer">612-626-0815</a><br>Minneapolis, MN 55414-3029   Cell: <a href="tel:(612)%20812-9952" target="_blank" rel="noreferrer">612-812-9952</a><br>===============================================<u></u><u></u></p></div></div></div></div></div></div>_______________________________________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (<a href="mailto:ARIN-consult@arin.net" target="_blank" rel="noreferrer">ARIN-consult@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-consult" rel="noreferrer noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-consult</a> Please contact the ARIN Member Services<br>
Help Desk at <a href="mailto:info@arin.net" target="_blank" rel="noreferrer">info@arin.net</a> if you experience any issues.</blockquote></div></div></div>