Subject: [ietf-privacy] Logging Recommendations for Internet-Facing Servers

From: S Moonesamy <[email-masked]>
Date: Thu, 05 Jun 2014 23:39:53 -0700

Hello,

BCP 162 contains logging recommendations for internet-facing 
servers.  Quoting the document:

   "Discussions about data-retention policies are out of scope for this
    document.  Server security and transport security are important for
    the protection of logs for Internet-facing systems.  The operator of
    the Internet-facing server must consider the risks, including the
    data and services on the server, to determine the appropriate
    measures.  The protection of logs is critical in incident
    investigations.  If logs are tampered with, evidence could be
    destroyed."

In other words, the BCP makes a recommendation without any discussion 
about privacy considerations.  The issue is traceability.  It has 
been the practice to log IP addresses.  Keeping the logs for years is 
not a good idea as it is difficult to argue that the information is necessary.

I suggest that the BCP be reconsidered given the lack of privacy 
considerations.

Regards,
S. Moonesamy

---

From: Linus Nordberg <[email-masked]>
Date: Sun, 15 Jun 2014 14:14:33 +0200

S Moonesamy <[email-masked]> wrote
Thu, 05 Jun 2014 23:39:53 -0700:

| I suggest that the BCP be reconsidered given the lack of privacy
| considerations.

+1

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jun 2014 13:51:57 +0100

Hi SM, Linus,

> | I suggest that the BCP be reconsidered given the lack of privacy

Q: How will that happen?
A: Someone will need to write an I-D:-)

If someone does such an I-D that is reasonable and improves
privacy, I'll be happy to help that progress.

Not sure if the BCP's RFC would need replacing or if updating
the BCP with a 2nd RFC would be right myself, so talking to
the original authors and/or the intarea list would seem wise.
They might also have other stuff they'd like to revise, who
knows. (The draft leading to this BCP [1] was an intarea [2]
draft.)

S.

[1] https://datatracker.ietf.org/doc/rfc6302/
[2] https://datatracker.ietf.org/wg/intarea/

> 
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy
> 
>

---

From: S Moonesamy <[email-masked]>
Date: Sun, 15 Jun 2014 11:38:20 -0700

Hi Stephen,
>privacy, I'll be happy to help that progress.

Ok.

>knows. (The draft leading to this BCP [1] was an intarea [2]

In theory a (future) RFC can be added to BCP 162.  In practice people 
won't read it or miss it.  A first step might be to talk to the 
authors to see what they would like to do.  The INTAREA working group 
[1] lacks the expertise to review privacy-related drafts.  People 
with an actual interest in privacy will have to participate in the 
working group and review the proposed update to BCP 162.

Regards,
S. Moonesamy

1. https://datatracker.ietf.org/wg/intarea/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Jun 2014 01:48:21 +0100

Hiya,

On 15/06/14 19:38, S Moonesamy wrote:
> won't read it or miss it.

Possibly fair point, but OTOH BCP10 and others consist of >1 RFC
and work. For now at least, I'd concentrate on how to the get the
new privacy-friendly stuff agreed, rather than worry too much as
to how its represented in RFC(s).

> A first step might be to talk to the authors
> to see what they would like to do.  The INTAREA working group [1] lacks
> the expertise to review privacy-related drafts.  People with an actual
> interest in privacy will have to participate in the working group and
> review the proposed update to BCP 162.

Who knows? I would agree that the intarea is probably not a hotbed
of privacy activists. But its also equally true that folks on that
list are probably as clueful as here, and so may well have quite a
good appreciation of how privacy is more important than previously.

So I'd say give it a whirl if you've the energy to write an I-D and
fwiw I'll try push forward with good work regardless of how its
locally received in one or another IETF WG (no matter the relevant
WG is an area-wg). But, equally, I'm not interested in helping with
work on things that haven't even tried to be run by the best list
of relevant/interested folks. I do get that that's not a very clear
distinction (sorry:-) but I hope it helps, and regardless am happy
to chat more, on and/or off list.

Cheers,
S.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Jun 2014 00:52:15 -0700

Hi Stephen,
>to chat more, on and/or off list.

I understood the explanation and I am okay with it.  I'll post a 
message to INTAREA.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Jun 2014 10:02:24 -0700

Hello,
>good appreciation of how privacy is more important than previously.

I am picking up the above for a general comment.  Currently, there 
isn't any IETF guidance about privacy.  A person may have a good 
appreciation of how privacy is more important than 
previously.  However, it may be difficult for the person to document 
the considerations in words which the IETF would find acceptable.

There is a message at 
http://www.ietf.org/mail-archive/web/int-area/current/msg03948.html 
which highlights the other considerations which can have an impact on 
privacy.  I would like to encourage anyone interested in privacy to 
comment about the topic on the INTAREA mailing list ( 
https://www.ietf.org/mailman/listinfo/int-area ).

Regards,
S. Moonesamy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Jun 2014 14:56:26 -0400

On 06/17/2014 01:02 PM, S Moonesamy wrote:
> I am picking up the above for a general comment.  Currently, there isn't
> any IETF guidance about privacy.  A person may have a good appreciation
> of how privacy is more important than previously.  However, it may be
> difficult for the person to document the considerations in words which
> the IETF would find acceptable.

I'm surprised to hear you say this, given that you're thanked in the
acknowledgments section of RFC 6973 (Privacy Considerations for Internet
Protocols).  Do you think that RFC doesn't provide useful guidance or
vocabulary?

	--dkg

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Jun 2014 13:03:10 -0700

Hi Daniel,
>Protocols).  Do you think that RFC doesn't provide useful guidance or

RFC 6973 was published in the IAB Stream [1].  Someone could argue 
that it is not an IETF document.  It is not possible to argue against 
that.  I reviewed RFC 6973 before it was published as a RFC.  In my 
opinion it contains useful guidance and vocabulary.  There is the 
following in RFC 6973:

   "Protecting against stored data compromise is typically outside the
    scope of IETF protocols.  However, a number of common protocol
    functions -- key management, access control, or operational logging,
    for example -- require the storage of data about initiators of
    communications.  When requiring or recommending that information
    about initiators or their communications be stored or logged by end
    systems (see, e.g., RFC 6302 [RFC6302]), it is important to recognize
    the potential for that information to be compromised and for that
    potential to be weighed against the benefits of data storage.  Any
    recipient, intermediary, or enabler that stores data may be
    vulnerable to compromise.  (Note that stored data compromise is
    distinct from purposeful disclosure, which is discussed in
    Section 5.2.4.)"

With hindsight I would say that I did not pay sufficient attention to 
the RFC 6302 reference in the above.  For what it is worth my last 
comments about RFC 6973 was dated February 2013.

Regards,
S. Moonesamy

1. http://www.rfc-editor.org/info/rfc6973

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Jun 2014 19:01:32 -0400

On 06/17/2014 04:03 PM, S Moonesamy wrote:
> RFC 6973 was published in the IAB Stream [1].  Someone could argue that
> it is not an IETF document.  It is not possible to argue against that. 

I think RFC 6973 makes it quite clear that it's intended to be relevant
for IETF work, even though it acknowledges that some things can't be
fixed or even addressed in IETF documents.  If someone wants to argue
that it's not an IETF document and therefore irrelevant, that sounds
unreasonable and bizarre to me.

At any rate, to the extent to which RFC 6302 describes and recommends
operational practices, and those operational practices have impacts on
the privacy of their users, the guidance in RFC 6973 clearly applies.

> I reviewed RFC 6973 before it was published as a RFC.  In my opinion it
> contains useful guidance and vocabulary.  There is the following in RFC
> 6973:
> 
>    vulnerable to compromise.

This sounds like a concrete rebuke to 6302 to me, since 6302 doesn't
even mention stored data compromise, let alone the risks associated with
it.  Scott Sheppard's responses in the int-area thread you pointed to
[0] doesn't seem to address this criticism at all.

>    (Note that stored data compromise is

Taken out of context, this parenthetical remark could be misunderstood
to mean "the earlier highlighted concerns about recommendations to log
are not relevant to purposeful disclosure".  But it is a trailing remark
of section 5.1.2 ("Stored Data Compromise"), and i think it was meant to
encourage the reader to consider deliberate disclosure in addition to
data compromise, not to preclude logging concerns from deliberate
disclosure.

Sheppard's responses in the int-area thread don't seem to take into
account any of the above concerns.

I agree that 6302 needs to be revisited.  I don't consider its
recommendations a best current practice.

	--dkg

[0] https://www.ietf.org/mail-archive/web/int-area/current/msg03948.html