Subject: [marf] Gen-ART review of draft-ietf-marf-redaction-04

From: <[email-masked]>
Date: Tue, 10 Jan 2012 21:44:16 -0500

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 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 may 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 reports
(e.g., hiding the local part [user] of an email address), while still allowing
correlation of the redacted information across related abuse reports from the 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 redaction
technique is to concatenate a secret string (called the "redaction key") to the
information to be redacted, apply "any hashing/digest algorithm", convert the 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 effectively 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, then the
output is highly vulnerable to dictionary and brute force attacks because only 6 bits
of entropy are added (the result may look secure, but it's not).  Beyond this extreme
example, this is a potentially real concern - e.g., applying the rule of thumb that
ASCII text contains 4-5 bits of entropy per character, the example in Appendix A
uses a "redaction key" of "potatoes" that injects at most 40 bits of entropy -
is that sufficient for email redaction purposes?

To take a silly example, if a CRC is used as the hash with that sort of short 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, and
	explain what is meant by "secure hash" in the security considerations section.
2) Require a minimum length of the "redaction key" string, and strongly suggest
	(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 printable
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 significantly
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 binary
key for HMAC would be a stronger approach. I suggest that authors consider
approach, but  there may be practical usage concerns that suggest not adopting it.

[2] The second open issue is absence of security considerations for the redaction
key.  The security considerations section needs to caution that the redaction key
is a secret key that must be managed and protected as a secret key.  Disclosure
of a redaction key removes the redaction from all reports that used that key.
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 what
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 source.

idnits 2.12.13 didn't find any nits.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "John Levine" <[email-masked]>
Date: 11 Jan 2012 04:38:02 -0000

>Please resolve these comments along with any other Last Call comments you may receive.

Hi.  I'm not one of the authors, but these issues have come up before.

>	- The hashing/digest algorithm may be weak.

Not really.  These are feedback reports, in which a recipient system
is sending back complaints that include copies of mail to the system
that originally sent it.  Any sender that keeps logs of outgoing mail,
which is all of them these days, need only use the time stamps and
sequence numbers in the headers, or any other per-recipient data in
the header or body of the message, to look it up in their own logs to
see who they sent it to.  This is a fundamental limitation of feedback
reports.

I can tell you from experience that I've done this to figure out who
to take off a list when their ISP tries to redact the complaint, and
it's not hard.  So in practice, even if the hash were extremely weak,
nobody would care because there are easier ways to recover the
address.  Complaint reporting systems like Spamcop have been trying
for years to redact complaints enough that senders can't "listwash"
(remove complainers from spam lists), and experience has shown that
it's basically impossible.

This hack is really just to make life a little easier for senders who
track complaint rates by recipient or recipient system, since 1
complaint each from N people means something different than N
complaints from one person.

It sounds like the security considerations didn't explain this
adequately.  Perhaps it would be better to fix the document to explain
more clearly why redaction is fundamentally weak rather than to worry
about what's akin to a steel lock on a cardboard box.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jan 2012 20:40:42 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 6:44 PM
> To: [email-masked]; Murray S. Kucherawy; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Gen-ART review of draft-ietf-marf-redaction-04

Hi David, thanks for the review.

> [...]

These are all good points.  My gut reaction is to say that this is all good advice and entirely correct but probably goes a little far for the problem space we're trying to address.  Thus, my inclination is to make the following changes (subject to WG consensus):

- add all of this advice to Security Considerations, with forward references to it elsewhere in the document
- make a SHOULD suggestion as to the minimum redaction key length (instead of a requirement)
- make a SHOULD suggestion as to the type of hash to be used (instead of a requirement)

Would those be sufficient?

> is a secret key that must be managed and protected as a secret key.
> Disclosure of a redaction key removes the redaction from all reports that used
> that key. 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.

Also a good point.  I don't think this is the right place to introduce advice about key rotation and the like as those are well-discussed concepts, so instead Security Considerations can simply make reference to such material elsewhere.  I'll go find some.  I know there's stuff like that in RFC6376 (DKIM) but I'm sure there are better ones.

> intended to be correlatable via string match across reports from the

Fair enough.  We can add a sentence to that effect in the Introduction.

To the MARF working group: Please let me know if the above suggestions suffice (reply only to the marf list, please).  I will summarize and have a new version ready to publish when LC closes, and make sure David sees it around the same time.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Jan 2012 21:30:11 -0800

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 

John and I collaborated on the following edits.  Please indicate whether or not you approve, and suggest any adjustments needed.  I'll include them in a revision right after IETF LC closes.

http://www.blackops.org/~msk/marf.html

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Jan 2012 00:37:35 -0500

On Tuesday, January 10, 2012 09:30:11 PM Murray S. Kucherawy wrote:
> John and I collaborated on the following edits.  Please indicate whether or
> not you approve, and suggest any adjustments needed.  I'll include them in
> a revision right after IETF LC closes.
> 

Looks good to me.

Scott K

---

From: <[email-masked]>
Date: Wed, 11 Jan 2012 01:56:48 -0500

Hi John,

> Hi.  I'm not one of the authors, but these issues have come up before.

Thank you - I appreciate the additional explanation and context.

> more clearly why redaction is fundamentally weak

That would definitely be useful, as I didn't find enough information in the
draft to help me understand what level of security is appropriate and why.

> to explain

As I noted in the review, the HMAC mechanism may not be appropriate, but
I do think that some of the draft content ought to be strengthened to prohibit
clearly wrong things such as the two examples in the review ("a" as redaction
key, CRC as hash/digest).

Thanks,
--David

> From: John Levine [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 11:38 PM
> To: [email-masked]
> Cc: Black, David
> Subject: Re: [marf] Gen-ART review of draft-ietf-marf-redaction-04
>

---

From: <[email-masked]>
Date: Wed, 11 Jan 2012 02:38:26 -0500

Hi Murray,

Thanks for the quick response.

> These are all good points.  My gut reaction is to say that this is all good advice and entirely
> correct but probably goes a little far for the problem space we're trying to address.  

That sounds reasonable to me, and I like John Levine's suggestion to add material to explain
more about the level of security that is appropriate for this problem space and why.  In light
of such an explanation, an HMAC-based mechanism could well be overkill.

> - make a SHOULD suggestion as to the type of hash to be used (instead of a requirement)

I have a hard time believing that the examples used in the review ("a" as the redaction
key, CRC as the hash) are ever acceptable, and for that reason, I think a couple of MUSTs
would be in order to prohibit that sort of nonsense.  In particular:

	- I think there ought to be a MUST minimum length requirement
		on the redaction key string to prevent really short ones.
	- I think use of a secure hash ought to be a MUST to prevent
		use of CRC and other bad ideas.

That could be accompanied by additional guidance that may or may not be "SHOULDs", e.g.,
suggest a SHA2 hash as a good secure hash, suggest use of a longer string than the
minimum requirement.

> Also a good point.  I don't think this is the right place to introduce advice about key rotation and
> the like as those are well-discussed concepts, so instead Security Considerations can simply make
> reference to such material elsewhere.  I'll go find some.  I know there's stuff like that in RFC6376
> (DKIM) but I'm sure there are better ones.

That would be fine - introducing the concept of key rotation as a means to reduce the impact of key
compromise accompanied by a reference to a longer explanation elsewhere seems reasonable.

Thanks,
--David

> From: Murray S. Kucherawy [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 11:41 PM
> To: Black, David; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04
> 
> These are all good points.  My gut reaction is to say that this is all good advice and entirely
> correct but probably goes a little far for the problem space we're trying to address.  Thus, my
> inclination is to make the following changes (subject to WG consensus):
> 
> Also a good point.  I don't think this is the right place to introduce advice about key rotation and
> the like as those are well-discussed concepts, so instead Security Considerations can simply make
> reference to such material elsewhere.  I'll go find some.  I know there's stuff like that in RFC6376
> (DKIM) but I'm sure there are better ones.
> 
> To the MARF working group: Please let me know if the above suggestions suffice (reply only to the marf
> list, please).  I will summarize and have a new version ready to publish when LC closes, and make sure
> David sees it around the same time.
> 
> -MSK

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Jan 2012 11:02:45 -0800

> 	explain what is meant by "secure hash" in the security considerations section.

Simply saying "any hash algorithm listed in [FIPS180-3]" is precise and sufficient.

> 	of an entropy-rich random number generator through a base64 converter).

Proposal: "The redaction key SHOULD be based on at least 64 bits of pseudo-random input that is converted to base64".

> of a redaction key removes the redaction from all reports that used that key.

Agree.

> redaction key in order to limit the effects of loss of secrecy for a single

Disagree, given that we have absolutely no idea how systems that use this will work operationally. Simply telling them "if it is no longer secret, you're hosed" is sufficient.

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Wed, 11 Jan 2012 11:50:20 -0800

Hi David,
At 18:44 10-01-2012, [email-masked] wrote:
>Gen-ART, please

I appreciate that you have spent your time and effort in performing 
the review.  I find the review useful.

>redaction key in order to limit the effects of loss of secrecy for a single

The comments are from a security perspective.  To be candid, 
redaction is silly as the email folks know how to get around 
that.  The secret key does not even have to be broken; a cookie in 
the message would get you the information you want.  The cost of 
preserving the secrecy is not worth it in my opinion.

Regards,
-sm

---

From: <[email-masked]>
Date: Wed, 11 Jan 2012 15:51:58 -0500

Hi,

Thanks for the response - I appreciate the perspective.

> preserving the secrecy is not worth it in my opinion.

At a minimum, I like John Levine's suggestion that the draft explain
the level of security required for redaction in practice.  Such an
explanation could help illuminate whether the secure hash (the
example in the draft uses SHA-1) is for obfuscation purposes
vs. actual security.

Absent such an explanation, I saw the use of a secure hash and inferred
the existence of actual security requirements.  If that was an incorrect
inference, then text should be added to the draft to avoid having
other readers make similarly incorrect inferences.

Thanks,
--David

> From: SM [mailto:[email-masked]]
> Sent: Wednesday, January 11, 2012 2:50 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04
> 
> Hi David,

---

From: SM <[email-masked]>
Date: Wed, 11 Jan 2012 13:15:12 -0800

Hi David,
>example in the draft uses SHA-1) is for obfuscation purposes

It would help to have an explanation along the line of John Levine's 
suggestion.

>other readers make similarly incorrect inferences.

Agreed.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jan 2012 15:16:50 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, January 10, 2012 9:38 PM
> To: [email-masked]
> > John and I collaborated on the following edits.  Please indicate
> > whether or not you approve, and suggest any adjustments needed.  I'll
> > include them in a revision right after IETF LC closes.
> >

Thanks for that.  Just to make sure our bases are all covered, the Gen-ART reviewer is pushing a little on the idea of saying the use of a secure hash ought to be a SHOULD, while we're currently using "suggested" given the non-critical use of security here.

So just to get it on the record, do we prefer the "suggested" language, or is a SHOULD more appropriate?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Jan 2012 18:18:57 -0500

On Wednesday, January 11, 2012 03:16:50 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Tuesday, January 10, 2012 9:38 PM
> > To: [email-masked]
> Thanks for that.  Just to make sure our bases are all covered, the Gen-ART
> reviewer is pushing a little on the idea of saying the use of a secure hash
> ought to be a SHOULD, while we're currently using "suggested" given the
> non-critical use of security here.
> 

I don't think the SHOULD is needed for interoperability or for security, so I 
think suggested is fine.

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 11 Jan 2012 21:34:07 -0500

In <[email-masked]>, on 01/11/2012
   at 11:02 AM, Paul Hoffman <[email-masked]> said:

>Proposal: "The redaction key SHOULD be based on at least 64 bits of
>pseudo-random input that is converted to base64".

Agree with the first part; disagree with mentioning BASE64 except as
an example.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Jan 2012 19:07:31 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shmuel Metz
> Sent: Wednesday, January 11, 2012 6:34 PM
> To: [email-masked]
> Agree with the first part; disagree with mentioning BASE64 except as an
> example.

Unless I misunderstand the mechanisms, I think the mention of base64 is superfluous anyway since the entropy applies to the hash step, not to the 7-bit encoding of the result.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 12 Jan 2012 08:46:23 +0100

On 12/Jan/12 00:16, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Scott Kitterman
>> 

+1

> Thanks for that.  Just to make sure our bases are all covered, the
> Gen-ART reviewer is pushing a little on the idea of saying the use
> of a secure hash ought to be a SHOULD, while we're currently using
> "suggested" given the non-critical use of security here.
> 
> So just to get it on the record, do we prefer the "suggested"
> language, or is a SHOULD more appropriate?

Saying "a secure hash is RECOMMENDED" (rather than "suggested")
doesn't really change the meaning, but makes the whole section overly
compelling.  To counter-balance that, I'd borrow some text from John's
post --such as the phrase "a steel lock on a cardboard box".

---

From: <[email-masked]>
Date: Thu, 19 Jan 2012 19:10:24 -0500

Based on discussion with the authors, the -05 version of this draft resolves the
issues raised in the Gen-ART review of the -04 version.  An important element of
the approach taken to issue [1] has been to explain why the security requirements
for redaction are significantly weaker than the strength of the secure hashes
that are suggested by the draft.

Thanks,
--David

> From: Black, David
> Sent: Tuesday, January 10, 2012 9:44 PM
> Cc: Black, David; [email-masked]; [email-masked]