[ARIN-consult] Fwd: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois Queries to Secure URL

[William Herrin]

> From: ARIN <info at arin.net>
> Subject: [ARIN-Suggestions] NEW ACSP 2018.3: Automatically Redirect Whois
> Queries to Secure URL
> Date: March 16, 2018 at 10:02:16 PDT
> To: arin-suggestions at arin.net
>
> On 14 March 2018, we received a new ACSP 2018.3: Automatically Redirect
> Whois Queries to Secure URL.
>
> https://www.arin.net/participate/acsp/suggestions/2018-3.html
>
> Description: It appears possible to go to the insecure version of ARIN's
> whois by going to http://whois.arin.net. Would ARIN be willing
> auto-redirect users to the secure version, https://whois.arin.net, and
> additionally, consider using HSTS for this site, too?
>
> Value to Community: Secures all WHOIS lookups, which could sometimes be
> potentially sensitive. It's also consistent with what ARIN has done with
> most of it's other public-facing websites.

Greetings,

I am AGAINST sending HTTP redirects (HTTP Location header) to upgrade
HTTP requests to whois.arin.net to HTTPS.

Security is comprised of the "CIA" triad: Confidentiality, Integrity
and Availability. Any security choice which harms the sum of these
three categories is a bad choice, even if it improves one of them.

Confidentiality is how well a system keeps secret information secret.
In general, whois requests to whois.arin.net are not sensitive in
nature, The exceptions have https available to them without requiring
any change to ARIN behavior. There is reasonable cause to believe that
folks who make http requests instead of https requests to whois would
gain no improvement to confidentiality. This isn't google search where
a user might search health or other sensitive information without
thinking about it, whois information just isn't sensitive.

Integrity is how well a system guarantees that the data received is
the correct data. In general, whois requests to whois.arin.net support
human not automated activity thus gain little from an improvement in
data integrity. The exceptions have https available to them without
requiring any change to ARIN behavior. More, the kinds of man in the
middle attacks which could be gainfully executed against the whois
service are challenging and rare to the point of non-existent. The
integrity improvement from forcing https is negligible at best,
particularly when any activity requiring greater integrity has https
available to it without requiring any change to ARIN behavior.

Availability is the likelihood that a system functions successfully
for the user. We should expect the existance of software querying
whois which does not support https and/or will malfunction if told to
execute a redirect (http location header). Perhaps the client doesn't
support https at all. Perhaps the client uses an old version of java
and the root of the certificate chain is not in the java key store.
There are plenty of reasons to expect a noticeable hit to system
availability should ARIN implement an http to https redirect.

No meaningful improvement to confidentiality and integrity.
Noticeable, potentially large hit to availability. Bad security plan.


HSTS is less offensive. The "Strict-Transport-Security" header is sent
only via HTTPS connections, never during ordinary HTTP connections. It
advises the supporting client software to remember and upgrade all
subsequent HTTP requests to HTTPS. The server acts exactly as before,
honoring both HTTP and HTTPS requests. Client software which does not
support HSTS acts exactly as before, sending requests via HTTP or
HTTPS as directed by the user. Only software built to understand HTTPS
and HSTS behaves any different.

>From the perspective of the CIA triad, HSTS offers negligible
improvements to confidentiality (no secrets), a very minor improvement
to integrity and a very minor hit to availability (HSTS is pretty new,
new stuff is buggy). Basically it's a neutral change in the security
posture.

Neutral changes run afoul of another core principle of information
security: The cost of a security feature must exceed the cost of not
having that security feature.Otherwise you're spending more money on
security than the information secured is worth, which is foolhardy.

There is an annualized dollar cost of implementing and operating HSTS.
There is an annualized risk-cost of not implementing HSTS. Who can
offer a credible argument that the annualized risk-cost of not
implementing HSTS for ARIN whois is something other than zero? I
cannot.

Regards,
Bill Herrin


-- 
William Herrin ................ herrin at dirtside.com  bill at herrin.us
Dirtside Systems ......... Web: <http://www.dirtside.com/>