From: <david.black@emc.com>
To: <ietf@cybernothing.org>, <msk@cloudmark.com>, <gen-art@ietf.org>,
 <ietf@ietf.org>
Date: Tue, 10 Jan 2012 21:44:16 -0500
Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04
Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQ==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: presnick@qualcomm.com, marf@ietf.org
Subject: [Gen-art] Gen-ART review of draft-ietf-marf-redaction-04
Precedence: list

I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR=
T, please
see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you m=
ay receive.

Document: draft-ietf-marf-redaction-04
Reviewer: David L. Black
Review Date: January 10, 2012
IETF LC End Date: January 18, 2011
IESG Telechat Date: January 19, 2011

Summary: This draft is on the right track but has open issues, described in=
 the review.

This draft specifies a method for redacting information from email abuse re=
ports
(e.g., hiding the local part [user] of an email address), while still allow=
ing
correlation of the redacted information across related abuse reports from t=
he same
source. The draft is short, clear, and well written.

There are two open issues:

[1] The first open issue is the absence of security guidance to ensure that=
 this
redaction technique effectively hides the redacted information.  The redact=
ion
technique is to concatenate a secret string (called the "redaction key") to=
 the
information to be redacted, apply "any hashing/digest algorithm", convert t=
he output
to base64 and use that base64 string to replace the redacted information.

There are two important ways in which this technique could fail to effectiv=
ely hide
the redacted information:
	- The secret string may inject insufficient entropy.
	- The hashing/digest algorithm may be weak.

To take an extreme example, if the secret string ("redaction key") consists=
 of a
single ASCII character, and a short email local part is being redacted, the=
n the
output is highly vulnerable to dictionary and brute force attacks because o=
nly 6 bits
of entropy are added (the result may look secure, but it's not).  Beyond th=
is extreme
example, this is a potentially real concern - e.g., applying the rule of th=
umb that
ASCII text contains 4-5 bits of entropy per character, the example in Appen=
dix A
uses a "redaction key" of "potatoes" that injects at most 40 bits of entrop=
y -
is that sufficient for email redaction purposes?

To take a silly example, if a CRC is used as the hash with that sort of sho=
rt input,
the result is not particularly difficult to invert.

I suggest a couple of changes:
1) Change "any hashing/digest algorithm" to require use of a secure hash, a=
nd
	explain what is meant by "secure hash" in the security considerations sect=
ion.
2) Require a minimum length of the "redaction key" string, and strongly sug=
gest
	(SHOULD) that it be randomly generated (e.g., by running sufficient output
	of an entropy-rich random number generator through a base64 converter).

For the latter change, figure out the amount of entropy that should be used
for redaction - the recommended string length will be larger because printa=
ble
ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each
8-bit character, and human-written text such as this message has significan=
tly
less).

>From a pure security perspective, use of HMAC with specified secure hashes
(SHA2-family) and an approach of hashing the "redaction key" down to a bina=
ry
key for HMAC would be a stronger approach. I suggest that authors consider
approach, but  there may be practical usage concerns that suggest not adopt=
ing it.

[2] The second open issue is absence of security considerations for the red=
action
key.  The security considerations section needs to caution that the redacti=
on key
is a secret key that must be managed and protected as a secret key.  Disclo=
sure
of a redaction key removes the redaction from all reports that used that ke=
y.
As part of this, guidance should be provided on when and how to change the
redaction key in order to limit the effects of loss of secrecy for a single
redaction key.

Editorial Nit: I believe that "anonymization" is a better description of wh=
at
this draft is doing (as opposed to "redaction"), particularly as the result=
 is
intended to be correlatable via string match across reports from the same s=
ource.

idnits 2.12.13 didn't find any nits.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778=
6
david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754
----------------------------------------------------