[Int-area] draft-andersdotter-intarea-update-to-rfc6302-00 comments

John Bambenek <jcb@bambenekconsulting.com> Fri, 27 April 2018 22:44 UTC

Return-Path: <jcb@bambenekconsulting.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7109129C59 for <int-area@ietfa.amsl.com>; Fri, 27 Apr 2018 15:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bambenekconsulting.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShoUgWS1fXyL for <int-area@ietfa.amsl.com>; Fri, 27 Apr 2018 15:44:00 -0700 (PDT)
Received: from chicago.bambenekconsulting.com (chicago.bambenekconsulting.com [99.198.96.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02980129C6A for <int-area@ietf.org>; Fri, 27 Apr 2018 15:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bambenekconsulting.com; s=default; h=Content-Transfer-Encoding:Content-Type :MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zrp7eEmegxo85qRweLtgqW56Xr9vxbcTRpSDS2B2Pr4=; b=xjq7C8/EHYM7N2uNia9f3coYNL erYEQvwjzavTkrNlFLifNz4CYRDOsr4eVIYfU9ONcvzd9t5Y/Zz5txi64dxHUnNmyv3ZVkFrrNmCH PBEOTLvfZv9C7WLJdYgMMj49y59wmM/X8JsOOjT4UXcmGIWBBCyYE7UuHa/CPB24bAnc=;
Received: from [72.2.0.174] (port=53078 helo=jcb.local) by chicago.bambenekconsulting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from <jcb@bambenekconsulting.com>) id 1fCC5t-0005RL-5j; Fri, 27 Apr 2018 18:43:57 -0400
To: int-area@ietf.org
From: John Bambenek <jcb@bambenekconsulting.com>
Openpgp: preference=signencrypt
Message-ID: <c5dd8a94-5f0c-e088-45c3-943ebdb33281@bambenekconsulting.com>
Date: Fri, 27 Apr 2018 17:43:57 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - chicago.bambenekconsulting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bambenekconsulting.com
X-Get-Message-Sender-Via: chicago.bambenekconsulting.com: authenticated_id: jcb@bambenekconsulting.com
X-Authenticated-Sender: chicago.bambenekconsulting.com: jcb@bambenekconsulting.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/3XLTv2mAwcvRg990eOEq8TWR5xE>
Subject: [Int-area] draft-andersdotter-intarea-update-to-rfc6302-00 comments
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2018 22:45:29 -0000

All-
New member here but this draft attracted my (and other of my colleagues)
attention. For reference, as a career I do investigations and
intelligence tracking cybercrime (and election related tomfoolery). My
comments are in the light of that.  My first comment is despite the
concern of GDPR, Recital 49 is a thing
(http://www.privacy-regulation.eu/en/recital-49-GDPR.htm). The biggest
use case for logging IP and port involves authentication events. So I
wanted to tackle the 5 recommendations individually. As an initial
point, GDPR isn't the only regulation game in town. Most other
regulations involving security (at least in the US) REQUIRES keeping
much of this information for a variety of periods of time. Getting in
the middle of dueling regulations is probably not a good thing, but I'd
argue that a priori, recital 49 allows this collection.

- SHOULD only store entire incoming IP addresses for as long as is
necessary to provide the specific service requested by the user.

Historical login information is often essential for a variety of
reasons. For instance, fail2ban tracked failed logins and then blocks
the underlying IP address for a defined period of time to prevent
brute-force attacks. Many user-profiling tools look at IP address for
abnormal logins (i.e. this person lives in the US, has only logged in
via US IP addresses, and now I see a login event from Russia). It is
essential for investigations that are often called after the fact. The
average "dwell time" for a breach in the US is about 6 months (most of
that time the entity is unaware). It is used to correlate multiple
malicious events. If the same IP address is hitting a web-server and
doing SSH brute forcing, and sending phishing docs... etc.  There are a
wide variety of reasons to store this information longer than just until
a "logout" event.

This requirement would all but criminalize everything we hold as
appropriate and a best practice in authentication.

- SHOULD keep only the first two octets (of an IPv4 address) or the
first three octets (of an IPv6 address) with remaining octets set to
zero, when logging.

This recommendation sounds like a middle-ground but it renders the
information complete useless for any use case I can think of. In many
cases, the first two octets wouldn't even tell me what country the user
is coming from. If I had to investigate an incident based on first two
octets of IP addresses along, I simply could not investigate at all.  If
data minimization is the goal and someone told me I could only log the
first two octets, I'd counter with why log them at all?  That's simply
filling disk with useless data.

- SHOULD NOT store logs of incoming IP addresses from inbound traffic
for longer than three days.

If breach time is 6 months, most of that being unknown, that would mean
I would be deleting essential investigatory information long before I'd
even know I needed it. If everyone did this, that would mean I would
need to know all but immediately I had an incident, law enforcement
would immediately have to be informed and start acting, and a legal
order to produce (or at least retain) information would have to be sent
to the other party. All within 3 days. If two of those days are Saturday
and Sunday, forget about it. If enacted, this willful evidence
destruction would several hamper the private sector and law enforcement
from every investigating an online incident.

The idea that all meaningful use of this data expires in 3 days does not
comport to how things work in the real world.

- SHOULD NOT log unnecessary identifiers, such as source port number,
time stamps, transport protocol numbers or destination port numbers.

This would fly in the face of almost every other regulatory regime. The
idea that I don't have a right to know when someone is logging into my
servers is mind-boggling. Recital 49 is a thing.  Further, if I were
attacked and need to subpoena the other party, if timestamps and ports
were simply never logged, quite literally, there would be minimal to no
ability to EVER investigate anything online again. I can't figure out
why transport protocol number would ever be considered sensitive. Does
whether someone used TCP or UDP really matter from a privacy perspective.

If this information was never logged, I wouldn't ever be able to
lawfully request this information from a third party or ISP to identify
someone. I can understate how much this would all but end meaningful law
enforcement investigations for any internet related case.

- SHOULD ensure adequate log access control, with suitable mechanisms
for keeping track of which entity accesses logged identifiers, for what
reason and at what time.

This I agree with this as a best practice FOR ORGANIZATIONS. One that
for the most part is already widely practiced. At least for those places
that can afford a SIEM. For any small organization, this would impose
purchasing or building (something that I don't think exists in
open-source) and imposing great costs. Many individuals and home users
may expose SSH or a VPN on their home routers. They'd never be able to
implement that.