[Hash] Preliminary minutes from the BoF
Paul Hoffman <paul.hoffman@vpnc.org> Fri, 05 August 2005 20:59 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E19IF-0003I1-EC; Fri, 05 Aug 2005 16:59:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E19I9-0003Hi-7E for hash@megatron.ietf.org; Fri, 05 Aug 2005 16:59:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03833 for <hash@ietf.org>; Fri, 5 Aug 2005 16:59:42 -0400 (EDT)
Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E19pG-0003ME-UV for hash@ietf.org; Fri, 05 Aug 2005 17:34:01 -0400
Received: from [10.242.21.248] (m975f36d0.tmodns.net [208.54.95.151]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j75KxYZx082181 for <hash@ietf.org>; Fri, 5 Aug 2005 13:59:36 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06230901bf195c64e060@[206.173.146.196]>
Date: Fri, 05 Aug 2005 14:13:02 -0400
To: Hash WG <hash@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 2.9 (++)
X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41
Cc:
Subject: [Hash] Preliminary minutes from the BoF
X-BeenThere: hash@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: hash.lists.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hash>
List-Post: <mailto:hash@lists.ietf.org>
List-Help: <mailto:hash-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=subscribe>
Sender: hash-bounces@lists.ietf.org
Errors-To: hash-bounces@lists.ietf.org
Many thanks to Pasi Eronen and Rich Graveman for taking notes! This is my combination of the two. Hash BoF IETF 63, Paris Monday August 1st, 1815-1945, room 341 Chair: Paul Hoffman Notes taken by Pasi Eronen and Rich Graveman, edited by Paul Hoffman 1. Paul Hoffman: Introduction (see slides) Introduced the BOF and rationale for it This deals only with collision resistance, not preimage resistance. 2. Bill Burr: NIST workshop NIST is organizing hash workshop on October 31 - November 1 If you want to attend you have to pre-register Expecting about 20 talks; the agenda will be posted in a couple of weeks Results of this workshop will help in us deciding whether to run a competition for hash functions, and policies regarding SHA-256 URL: http://www.nist.gov/hash-function 3. Russ Housley: Preprocessing to strengthen current hash functions (presenting on Michael Szydlo's behalf) (see slides) Eric Rescorla: As a defense, how specific this is to current techniques of attacking hash functions? Russ: This defeats the currently-known attacks, but not all unknown attacks. Basically we don't know how wide class of attacks this defeats. The paper has some more details. 4. Ran Canetti: Randomized hashing in signatures (see slides) Eric Rescorla: One concern people often have about if attacker can control initial value, it makes forgeries easier. Ran: You need to incorporate randomness in some other way than IV. Eric: 2nd thing, how much randomness you need? Ran: Any amount is better than none, at most 512 bits (the function's block size). Uri Blumenthal: Are there any calculations to prove this randomized is any better than non-randomized? Ran: With current SHA-1 attacks, randomness helps in transforming off-line brute-force attack to on-line. Uri: In some cases it is a problem to come up with even 128 bits of randomness for every signature or hash. Also questioned how to calculate how much randomness you need and how much it helps. 5. Steven Bellovin: Analyzing hash agility in IETF protocols (see slides) Stephen Kent: When looking at this, did you consider handling this with configuration of trust anchors? Bellovin: If IPsec is used in relatively closed environment, it might work. But for things like TLS, probably not. 6. Tim Polk: Hash truncation at NIST (see slides) Donald Eastlake: Why not put the truncation length every 12 bytes, like the "whitening" earlier? Tim Polk: Currently, we only put it in IV. But I'll take this idea to the editors 7. Paul Hoffman: Charter discussion (see slides) Paul: Let's start with the charter from the list but feel free to amend it. Also, let's discuss if this should be in the IETF or the IRTF. Wes Hardaker: I haven't read the charter. I'm confused what exactly is within the scope. We have 4000 RFCs and someone needs to grep for hash functions. Paul: That's not included right now. Wes: It seems the output would be guidance to the rest of IETF, mandated reading. Uri: Designing a hash function is not appropriate for either IETF or IRTF. Collecting requirements, or designing modes like truncated hashes, or recommendations on how to use a hash function, could belong here. Larry Masinter: IETF should do things are needed and only IETF will do, not things that are needed but someone else is likely to do. Designing hash algorithms is the latter, going through through IETF protocols is clearly former, so maybe it should be in the charter. Paul: draft-hoffman-has-attacks-04 concludes that in most IETF protocols the attacks don't really matter. The main exception is certificates, and the attacks are not yet useful. Jon Callas: Randomized hashing or whitening is interesting, we could implement it in OpenPGP in a couple of hours. But what should we doing? There are workshops coming soon. If I have an objection to making a charter, it's only that we should wait for Vancouver to have more information. Gregory Lebovitz: I think doing all protocol work here is not a good idea, rather produce coaching to other WGs that can then update their protocols. Ran: I agree that IETF or IRTF should not design hash functions. Standardizing modes of operation for hash functions, yes. IETF is sometimes more agile than other organizations, for instance HMAC started here, and was then used elsewhere. Paul: Talking about BCPs, we also need to decide whether we want to have a one recommendation/answer for the next hash function, or several. Several gives flexibility, but may confuse the audience. Uri: Our job is not designing modes of operation, but standardizing modes designed and thoroughly peer-reviewed elsewhere. I don't think we're at that point yet with things like randomized hashing. We also need to collect input from not only protocol people, but also hardware; it would not be good if our design is 10x slower than SHA-1. Paul: Some people are implementing SHA1 in hardware, are we making that hardware obsolete? Steven Bellovin: We could do an informational RFC based on the paper by Eric and I, e.g. how to design protocol for hash function agility. Second thing that is needed is analyzing more protocols than Eric and I did to see what works and what not. Eric: We currently have partial information. We know some things we have are weak. In the first stage, we can patch things and provide input/requirements to people designing new hash functions. In stage two, we would replace things with things that come out from standardization process elsewhere, like new hash functions. David Black: I also support producing BCPs, one important thing to decide is to when to publish that BCP, when we're sufficiently confident to recommend something. This is important also outside the IETF. On the hardware issue, SHA-1 is pain in hardware, being as fast as SHA-1 might not be sufficient requirement. Wes Hardaker: People need guidance in rollover and algorithm negotiation. Paul: If we do some work, is it BCPs? (Some nodding and humming) Yes, it looks like most people are. Aaron Falk (IRTF chair): BCP does not sound like research to me, so this sounds more like IETF than IRTF. The IRTF is mostly about doing our own research before handing it off to the IETF. It depends on how you want to scope the work. Shorter-term protocol work would better fit in IETF, longer-term work maybe in CFRG research group? Ran: As CFRG co-chair, some of this is clearly within scope of CFRG. But also would make sense to have a focused IETF working group. Christian Huitema: I would like to see IETF WG working at least on negotiation mechanisms. Jim Touch: We seem to be talking mainly about hashes within scope of signatures, but signature algorithms are out of scope. Is this a good idea? Paul: More needs to be discussed on the mailing list. (end) --Paul Hoffman, Director --VPN Consortium _______________________________________________ Hash mailing list Hash@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hash
- [Hash] Preliminary minutes from the BoF Paul Hoffman