Re: [saag] [Cfrg] RFC analyzing IETF use of hash functions [was: Re: Further MD5 breaks: Creating a rogue CA certificate]

thanks for volunteering, Sean.

On Jan 5, 2009, at 7:33 PM, Sean Shen wrote:

> Hi,
> A draft in CSI work group gives some analysis on hash threats on
> CGA(RFC3972) and SeND(RFC3971). Hope it also provides valuable info.
> I will be happy to give review or other possible support for this  
> valuable
> work.
>
> Best,
>
> Sean
>
>> -----Original Message-----
>> From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On
>> Behalf Of Sean Turner
>> Sent: Tuesday, January 06, 2009 11:21 AM
>> To: David McGrew
>> Cc: cfrg@irtf.org; saag@ietf.org
>> Subject: Re: [saag] RFC analyzing IETF use of hash functions
>> [was: Re: [Cfrg] Further MD5 breaks: Creating a rogue CA certificate]
>>
>> Dave,
>>
>> When the S/MIME WG penned
>> http://tools.ietf.org/html/draft-ietf-smime-multisig-05 we
>> added an appendix that addresses where hashes are located in
>> CMS's SignedData and the attacks against those hashes.  I'd be
>> willing to help craft any other wording necessary for S/MIME|CMS.
>>
>> spt
>>
>> David McGrew wrote:
>>> Hi Ran,
>>>
>>> I think it is a great idea to document the IETF applications/uses of
>>> hashing, and the attacks against particular uses of hashing.
>> It would
>>> make a great CFRG informational RFC, if we can find volunteers to
>>> contribute to and edit it.  I offer to review it.
>>>
>>> David
>>>
>>> On Dec 31, 2008, at 7:48 AM, RJ Atkinson wrote:
>>>
>>>>
>>>> [Distribution trimmed slightly to reduce cross-posting and
>> improve SNR.]
>>>>
>>>> On  30 Dec 2008, at 20:20, Peter Gutmann wrote:
>>>>> The current MD5 attack is very cool but there's no need to
>> worry about
>>>>> bad guys doing much with it because it's much, much easier to get
>>>>> legitimate CA-issued certs the normal way, you buy them just like
>>>>> everyone else does (except that you use someone else's credit card
>>>>> and identity, obviously).
>>>>
>>>>
>>>> Two thoughts:
>>>>
>>>> 1) Protocol Issues
>>>>
>>>> The IETF ought to be thinking about a wide range of IETF protools
>>>> in the same way that Peter thinks about CA security issues above.
>>>>
>>>> For some IETF protocols, for example all of the IGP authentication
>>>> extensions (excepting RFC-2154, AFAICT), active non-cryptographic
>>>> attacks are feasible (if not yet seen in the deployed world,  
>>>> AFAICT)
>>>> that are much easier than *any* cryptographic attack.  Again, and
>>>> only by way of example, RFC-4822 discusses some of these that are
>>>> specific to RIPv2 authentication.
>>>>
>>>> For protocols where non-cryptographic attacks are feasible AND
>>>> are lower cost than a cryptographic attack, really it does not make
>>>> much difference what cryptographic algorithm gets deployed by a  
>>>> user
>>>> -- and the IETF's focus should be on improving the underlying 
>>>> authentication mechanism BEFORE worrying about which cryptographic
>>>> algorithms are being deployed.
>>>>
>>>> Attackers are generally both smart and lazy, so they won't waste
>>>> time on an expensive cryptographic attack when a lower effort
>>>> non-cryptographic attack exists.
>>>>
>>>>
>>>> 2) Hash algorithm analysis
>>>>
>>>> It would be very helpful if a *set* of mathematicians/ 
>>>> cryptographers
>>>> could jointly put together a summary of the known attacks on all
>>>> the widely used hash algorithms (e.g. MD2, MD4, MD5, SHA-0, SHA-1,
>>>> SHA-2, others), *including references to the published literature*.
>>>>
>>>> Ideally, this analysis would also include discussion of
>> whether those
>>>> attacks apply for those same algorithms when used in the
>> modes employed
>>>> by various IETF protocols today (e.g. Keyed-Hash as used in
>> OSPFv2 MD5
>>>> or RIPv2 MD5, HMAC-Hash, and so forth).
>>>>
>>>> This would be most useful to have as an Informational RFC,
>>>> and SOON, so that IETF WGs could have some "consensus" document
>>>> to refer to -- and to cite explicitly -- if any IETF WGs decide
>>>> to make hash algorithm recommendations or decisions.
>>>>
>>>> I don't understand IRTF process details perfectly, but perhaps
>>>> the CFRG chairs might undertake creating such a document as a
>>>> near-term official CFRG group project.
>>>>
>>>> Yours,
>>>>
>>>> Ran
>>>> rja@extremenetworks.com
>>>>
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>> Cfrg@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag