Subject: [marf] Use of hashes in draft-ietf-marf-redaction

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Jan 2012 12:59:45 -0800

The redaction and authfailure-report documents are now in their second IETF Last Calls.  So far, so good.

We can expect a comment from the IESG wondering why in the redaction document we didn't specify a particular hash algorithm.  My reply so far (i.e., informally) is that it's not necessary.  The agent generating the reports can select whatever hash it wants to use; if it's willing to risk collisions at the cost of cheaper processing, it can pick the weaker hashes.  If it's satisfied with ROT13, it could even use that.  The point here is to obscure the original string to the satisfaction of the report generator while allowing the report receiver to observe that multiple reports are referring to the same end user.  The report receiver can then apply whatever tricks it wants to use to track the report back to the offending user once it gets a collection of such reports.  Basically, the usual concerns about a collision attack don't apply to this use of hashes since the same party that produces the hashes also consumes them.

So two questions:

1) Is that a reasonable reply?

2) Should the above be added as an Appendix?

The AD I spoke to seems happy with this, and suggests that adding such text would help but it's not strictly necessary.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2012 23:11:43 -0000

> Basically, the usual concerns about a collision attack don't apply to this
> use of hashes since the same party that produces the hashes also consumes them.

Right.  A spec like this needs to define the parameters needed to
interoperate, and the hash isn't one of them.

Also, anyone who spends five seconds thinking about the threat model
should realize that people will reverse engineer the hashed names by
using other info about the messages to figure out what message was
sent to whom, and anything that isn't trivially reversible (sorry,
rot13) is adequate.

>1) Is that a reasonable reply?

Yes.

>2) Should the above be added as an Appendix?

Don't see why.  Perhaps we could do a separate BCP called something
like "Excessive preoccupation with low level technical nits considered
harmful."

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 07 Jan 2012 13:28:16 +0100

On 06/Jan/12 21:59, Murray S. Kucherawy wrote:
> 
> The point here is to obscure the original string to the
> satisfaction of the report generator while allowing the report 
> receiver to observe that multiple reports are referring to the
> same end user.

Yes, indeed ARF recommends the /identity hash/ --that replaces a
string with itself.  SHA1 is exemplified in Appendix A, anyway.

> Basically, the usual concerns about a collision attack don’t apply
> to this use of hashes since the same party that produces the hashes
> also consumes them.

Replacing a string with "xxxxxxxx" gives better protection by
preventing any correlation.  That has a 100% collision rate.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sat, 07 Jan 2012 17:47:08 -0500

In
<[email-masked]>,
on 01/06/2012

>1) Is that a reasonable reply?

Yes. The question of specifying a particular hash has been hashed <g>
to death here, and the consensus seems clear.

Yes.

-- 
     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)