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

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 01 Feb 2017 12:12:36 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-intarea-hostname-practice-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-hostname-practice/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

You may want to add a security consideration for incident responders. 
When researching an incident, it is common practice to grab the current
name of a IP and associated DNS information.  This information gets
passed to other incident response teams or those involved in
tracking/researching attack related information.  The attackers are
already changing DNS entries, this will make it easier for them and
harder for incident handlers to track and manage incidents.

Thanks for your work on this draft.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 2 Feb 2017 07:08:17 -1000

On 2/1/2017 10:12 AM, Kathleen Moriarty wrote:
> ...
> harder for incident handlers to track and manage incidents
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?

-- Christian Huitema

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 Feb 2017 13:45:32 -0500

> prefer something specific to incident response, or should we write

Thanks, Christian.  Something more generic and maybe in the security
section as it's used in a security function to track attackers.

Kathleen

-- 

Best regards,
Kathleen

---

From: Christian Huitema <[email-masked]>
Date: Thu, 2 Feb 2017 13:47:25 -1000

> 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" ?

-- Christian Huitema

---

From: [email-masked]
Date: Thu, 2 Feb 2017 21:55:26 -0500

Please excuse typos, sent from handheld device 

> On Feb 2, 2017, at 6:47 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> 

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

---

From: Rolf Winter <[email-masked]>
Date: Fri, 3 Feb 2017 09:08:45 +0100

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

---

From: [email-masked]
Date: Fri, 3 Feb 2017 07:13:29 -0500

> On Feb 3, 2017, at 3:08 AM, Rolf Winter <[email-masked]> wrote:
> 
> 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.

That works for me.  

Thank you,
Kathleen

---

From: Christian Huitema <[email-masked]>
Date: Fri, 3 Feb 2017 15:19:42 -1000

>> 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 exa…

I just posted an updated -05 version. The security section now includes
the paragraph suggested by Rolf that we just agreed on. The other
changes are the s/huitema/thaler/g in section 3 that Stephen suggested,
a reference to RFC 1983 to have a definition of FQDN as suggested in
Lionel Morand's review, and a couple of minor edit fixes also suggested
by Lionel.

-- Christian Huitema

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 6 Feb 2017 14:52:31 +0000

On Feb 3, 2017, at 8:19 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
> On 2/3/2017 2:13 AM, [email-masked] <mailto:[email-masked]> wrote:
>> 

Thanks Christian. I have gone through the new version and it addresses the two outstanding comments from IESG evaluation. I will go ahead and approve this version.

Regards
Suresh