Re: [Int-area] Kathleen Moriarty's Yes on draft-ietf-intarea-hostname-practice-04: (with COMMENT)

Rolf Winter <rolf.winter@hs-augsburg.de> Fri, 03 February 2017 08:08 UTC

Return-Path: <rolf.winter@hs-augsburg.de>
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 E5FAD12951F; Fri, 3 Feb 2017 00:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Level:
X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 6Nr4R1xhQZZn; Fri, 3 Feb 2017 00:08:52 -0800 (PST)
Received: from fly.RZ.HS-Augsburg.DE (fly.RZ.HS-Augsburg.DE [141.82.217.48]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104A41293FE; Fri, 3 Feb 2017 00:08:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by fly.RZ.HS-Augsburg.DE (Postfix) with ESMTP id 915551D607C; Fri, 3 Feb 2017 09:08:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de
Received: from fly.RZ.HS-Augsburg.DE ([127.0.0.1]) by localhost (fly.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g3MOAiXmwTVX; Fri, 3 Feb 2017 09:08:44 +0100 (CET)
Received: from [192.168.1.149] (nightswatch.informatik.hs-augsburg.de [141.82.79.79]) by fly.RZ.HS-Augsburg.DE (Postfix) with ESMTPSA id D5FE91D6124; Fri, 3 Feb 2017 09:08:43 +0100 (CET)
To: kathleen.moriarty.ietf@gmail.com, Christian Huitema <huitema@huitema.net>
References: <148597995644.19147.5662596058741679761.idtracker@ietfa.amsl.com> <98a7c881-0e44-59ae-f820-41f0a57d5d0f@huitema.net> <CAHbuEH4oq7iq1xWnYPAhvzxGYUS4fPNVvJP1QO2pij95i+N4cw@mail.gmail.com> <e2fa2d68-e1f5-8f29-74a8-ff0ea9e6e298@huitema.net> <E0712FCA-6E3C-4F09-B33B-AE443E4C5052@gmail.com>
From: Rolf Winter <rolf.winter@hs-augsburg.de>
Organization: Conntac
Message-ID: <47a89721-807e-f4c2-1503-7ca77a9833ca@hs-augsburg.de>
Date: Fri, 03 Feb 2017 09:08:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <E0712FCA-6E3C-4F09-B33B-AE443E4C5052@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/lLNtxiflk8mZOKwRo_7hT-9tRWA>
Cc: draft-ietf-intarea-hostname-practice@ietf.org, int-area@ietf.org, The IESG <iesg@ietf.org>, intarea-chairs@ietf.org
Subject: Re: [Int-area] Kathleen Moriarty's Yes on draft-ietf-intarea-hostname-practice-04: (with COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.17
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, 03 Feb 2017 08:08:54 -0000

Hi,

Randomized hostnames might have implications in places we do not even 
think about for now, so why not take this as a mere example. Also, it 
seems that the randomization might not be the problem but the time 
between changes of a name, if tracking is the only use case. How about:

There are obvious privacy gains to changing to randomized hostnames and 
also to change these names frequently. Wide deployment might however 
affect security functions or current practices. For example, incident 
response using hostnames to track the source of traffic might be 
affected.  It is common practice to include hostnames and reverse lookup 
information at various times during an investigation.

Best,

Rolf


Am 2/3/17 um 3:55 AM schrieb kathleen.moriarty.ietf@gmail.com:
>
>
> Please excuse typos, sent from handheld device
>
>> On Feb 2, 2017, at 6:47 PM, Christian Huitema <huitema@huitema.net> wrote:
>>
>>
>>
>>> On 2/2/2017 8:45 AM, Kathleen Moriarty wrote:
>>>> On Thu, Feb 2, 2017 at 12:08 PM, Christian Huitema <huitema@huitema.net> wrote:
>>>> ...
>>>> OK. This is the classic tension between privacy and management, and we
>>>> can certainly add a statement in the privacy section. Kathleen, do you
>>>> prefer something specific to incident response, or should we write
>>>> something more generic?
>>> Thanks, Christian.  Something more generic and maybe in the security
>>> section as it's used in a security function to track attackers.
>> How about saying something like "In managed environments, the hostname
>> is often used as part of incident response
>> or other security related functions. Mitigations for the hostname
>> related privacy
>> issues will need to consider the effect on these functions" ?
>
> Hmm, I'll have to think about it more as the host names they are typically sharing is that of the attacker.  The above reads as if it's the hostname of the managed environment that should be considered.
>
> Feel free to tweak to use the language you have in the draft, how about:
> Although there are privacy gains to changing randomized hostnames, wide deployment will affect security functions like incident response who use hostnames to track the source of traffic.  It is common practice to include hostnames and reverse lookup information at various times during an investigation.
>
> It's more specific than what you were looking to include, but accurate in terms of a consideration with this change.
>
> Thank you,
> Kathleen
>>
>> -- Christian Huitema
>>