Re: [ARIN-consult] Whois using these ARIN services?? (fwd: Consultation on the Future of ARIN’s Directory Services)

[Jay A via NANOG <nanog () lists nanog org>]

On Tue, Sep 1, 2026 at 12:09 PM Tom Beecher via NANOG
<nanog () lists nanog org> wrote:

> There is no way to use WHOIS that is NOT at risk of in-flight manipulation.

Not exactly. You can whois query the same items several iterations over
various periods of time from multiple network perspectives if you want.

You can render the probability low enough that it is not a risk worth
considering.
Which is equal to a zero risk.  The possibility of an in-flight
manipulation does not matter
for some consumers and applications.  So not fundamentally part of the Whois
server nor ARIN's attack surface.

Mail operators are running email transport protocols over 25 which
send messages
in the clear and using Whois to find IP address contacts for issue reporting.
Encrypting the Whois transport does not add security to the common use case,
because the underlying protocol itself for email transmission is in the clear.
Your security can never be greater than the weakest link in the chain,
so the fact
that the underlying SMTP transport is in the clear means that Whois in
the clear
has a zero risk component in that case.

Even if the Whois transport is not encrypted: the transport does not
authenticate that
the data has not been tampered with at rest while on ARIN's servers
nor after your
client has received it before displaying in the terminal.

And the risk can be near zero because most applications of Whois data are simply
for finding a contact in order to report a problem, abuse, or begin an
investigation.
Only specific applications, such as verifying a contact have a real risk.

It is also irrelevant to ARIN's attack surface, since this has always
been an inherent
well-known trait to the WHOIS protocol itself which affects only the consumer's
security not the server operator's.  And the consumer can mitigate it.

There is nothing about the Whois protocol which prevents the server
from creating
a timestamped digital signature footer in the response, and it could
be solved within
the bounds of the existing protocol.

I would say that RDAP ought to be first fully implemented with full
parity regarding Whois
and Whois-RWS query and output  result selection/filterting features,
and have wide support
across major OSes first and the N years sunset dates should be set 2
years after that
happens.     The year or less sunset on those protocols is way too low.

Rdap is not widely supported on the client yet, and the simplest common
end user use case;  WHOIS on 1 ip address   to be read by a human
does not benefit at all from the  "upgrade" to RDAP.

--
-J
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/LOHMQV2WGROMHSCYMFJILDFNBYK4IG7H/