Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"

"David McGrew (mcgrew)" <> Wed, 14 November 2012 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE37F21F85E1 for <>; Wed, 14 Nov 2012 05:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZJ2MlmUS5xn0 for <>; Wed, 14 Nov 2012 05:14:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0562021F85DA for <>; Wed, 14 Nov 2012 05:14:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3277; q=dns/txt; s=iport; t=1352898876; x=1354108476; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+nz///41PT3htrU7A/mLCRckEsGcdFHsSgq55lqnI9w=; b=A5RrHSI78K3HInBnv/H7hPueLjf/OxprhHJK8dfgvBXCb5kkRO7YWL42 Ixg5q2Nj6fPvludtZy4hL/WQibcDYui9L/tbmAtiAP3zmc4Gn9Sd5GsIR aQ303a2fMx59df6iuOQJSRBr5ewjFgJ4v9C8H6em9r792BXIcJ0ww7bjN c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALeYo1CtJV2a/2dsb2JhbABEDsMvgQiCHgEBAQQBAQEPASc0CxIBCBgKFDcLJQIEAQ0FCBqHaAuacKAOjC2FS2EDlxiNPIFrgjI9ghk
X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="139275762"
Received: from ([]) by with ESMTP; 14 Nov 2012 13:14:35 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qAEDEZr6018571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 13:14:35 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 07:14:35 -0600
From: "David McGrew (mcgrew)" <>
To: Joe Touch <>, Paul Hoffman <>
Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
Thread-Index: AQHNweyKBFECjqGD4EK+xvmKz2CDQJfpYOIA
Date: Wed, 14 Nov 2012 13:14:34 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--43.062700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF Security Area Advisory Group <>
Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Nov 2012 13:14:37 -0000

Hi Joe and Paul,

On 11/13/12 5:16 PM, "Joe Touch" <> wrote:

>Hi, Paul (et al.),
>This doc refers to IETF protocols that use hashes, but doesn't discuss
>any in specific. It also doesn't address how hashes are used, e.g., solo
>(as a fingerprint), keyed (for authentication and source confirmation),
>as part of an HMAC, or as part of key derivation.
>That sort of information might be additionally useful, IMO.

I think you (Joe) have a valid point about how the draft could be
improved, though the draft does address the use question somewhat (it even
has a section on "How Internet Protocols Use Hash Algorithms").

I have a suggestion: the draft could

1) more precisely define the different ways that hash functions are used
in more detail (in signatures, in HMAC, KDFs, other message authentication
codes, integrity checking, ...)   The definitions should be clear enough
that a relative crypto novice, looking at a specification that describes a
use of a hash function, could correctly categorize that use.

2) relate the security of each use case to the collision/first
preimage/second preimage attacks

3) have a section that describes uses of hash functions in Internet
protocols that rely on collision resistance.   (My thinking here is that
there are many uses of hash functions, and so we should focus on the most
security critical cases)

If we had an RFC with these clear categories in them, then we could
categorize new uses of hash functions that appear in new drafts, perhaps
focusing on the cases where collision resistance is required.   This could
be part of the SECDIR review process, or perhaps some other independent
process (for instance, send an automatic message to the authors pointing
out the hash function in their draft and the categories in the RFC).
Yes, I realize that there are a lot of of RFC and drafts using hash
functions, and that this is a non-trivial amount of work. But consider how
much better off we would be now if we had started categorizing uses of
hash functions in RFCs back in y2k ...

What do you think?


>On 11/8/2012 4:29 AM, Paul Hoffman wrote:
>> Greetings again. Bruce Schneier and I have started an update to RFC
>>4270, "Attacks on Cryptographic Hashes in Internet Protocols". This
>>revision is meant to deal with new and more devastating attacks on MD5,
>>the fact that SHA-1 collisions will be financially feasible in the
>>foreseeable future, and NIST's upcoming SHA-3 announcements. We expect
>>to keep this revision process open for at least five months because NIST
>>probably won't finalize the parameters and naming and so on for KECCAK
>>until then; that is, we won't send this to RFC Editor until SHA-3 is
>>finalized. Please take a look at
>> Sean and Stephen have agreed that we should use the SAAG mailing list
>>for discussing this draft.
>> --Paul Hoffman
>> _______________________________________________
>> saag mailing list
>saag mailing list