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

Daniel Kahn Gillmor <> Tue, 17 June 2014 23:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E01771A00ED for <>; Tue, 17 Jun 2014 16:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XJ2uzElpcN2s for <>; Tue, 17 Jun 2014 16:01:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E9981A008F for <>; Tue, 17 Jun 2014 16:01:46 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id E8D25F984; Tue, 17 Jun 2014 19:01:42 -0400 (EDT)
Message-ID: <>
Date: Tue, 17 Jun 2014 19:01:32 -0400
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
To: S Moonesamy <>,
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="C51LU8FlBOlS1Nxer4CQmkWKVLVFb9abJ"
Subject: Re: [ietf-privacy] Logging Recommendations for Internet-Facing Servers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jun 2014 23:01:49 -0000

On 06/17/2014 04:03 PM, S Moonesamy wrote:
> Hi Daniel,
> At 11:56 17-06-2014, Daniel Kahn Gillmor wrote:
>> 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?
> 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:
>   "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.

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
>    distinct from purposeful disclosure, which is discussed in
>    Section 5.2.4.)"

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

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.