Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt

["Christopher Morrow" <[e-mail]>]

(initially sent with wrong src-addr, apologies)

On Fri, Dec 5, 2008 at 7:25 AM, Christopher Morrow
<[e-mail]> wrote:
> On Fri, Dec 5, 2008 at 1:54 AM, Joel Jaeggli <[e-mail]> wrote:
>> Glen Kent wrote:
>>> Hi,
>>>
>>> Overall, the draft looks in good shape and i support it.
>>>
>>> One small comment though - I think their concern regarding the lack of
>>> security offered by MD5 for the routing protocols is misplaced. I am
>>> referring to the Introduction in that above draft. I agree that while
>>> it might be possible to spoof an acceptable MD5 digest, it is near
>>> impossible to spoof what might be an acceptable routing protocol
>>> packet with an acceptable spoofed digest.So, the authors might want to
>>> tone down their concern in that section!
>>
>> The general problem of being able to produce collisions with md5 digests
>> does kind of make one inclined to deprecate their use when possible even
>
> to be able to make a collision with content worthwhile to the problem
> space seems very limited, knowing the key and spitting out a packet on
> the wire which is signed would be far simpler.
>
>> when there are a limited set of circumstances  under which it can be
>> exploited. MD5 is used in lots of places and it will take a very long
>> time to remove it from many of them... The law of unintended
>> consequences says if I leave the MD5 library in my toolchain someone
>> will eventually use it for some purpose for which it is totally unsuitable.
>>
>
> I agree that longer term migrating away so it's not re-used in a bad
> place/way is fine... I think people often stop with: "Md5 has
> collisions so we shouldn't use it" before asking if making a collision
> in their circumstances is relevant or possible in a timely fashion.
>
>> I think description of the deprecation of md5 limitations in paragraph 3
>> of the introduction could use some help.
>>
>> one document that similarly addressed this subject I saw recently was:
>>
>> http://tools.ietf.org/html/draft-ietf-dnsext-tsig-md5-deprecated-01
>>
>> the security considerations second of which describes to motivation
>> fairly well.
>>
>> One concern I would express in the context of how this is done today is
>> the persistence of the shared secret used to protect these sessions is
>> measured in years notwithstanding the issues around storing things that
>> persist that long an attacker with access to the packet stream can avail
>> themselves of the opportunity to try to perform tradition brute force
>> activities to generate the secret used to hash the data and generate the
>> digest the salt in these protocols (eg tcpmd5) is sufficiently large to
>> render rainbow tables infeasible...
>>
>
> the secrets stay the same because someone though adding md5 auth to
> routing protocols was a good thing (which is probably is in some/many
> cases) but stopped there. There was never any thought put into the
> operations of the system, just the 'security'... Key rollover/change
> is significantly painful that pretty much no one actually does it.
>
> -Chris
>
>> That's not really for this draft but it is worth thinking about longer term.
>>
>>> Glen
>>>
>>> On Tue, Dec 2, 2008 at 7:32 AM, Bhatia, Manav (Manav)
>>> <[e-mail]> wrote:
>>>> Hi,
>>>>
>>>> We have posted a revised version of the "Cryptographic Authentication
>>>> Algorithm Implementation Best Practices for Routing Protocols".
>>>>
>>>> This has been updated based on the feedback from the list and the IETF
>>>> meet where it was suggested that we should (i) do away with the
>>>> additional RFC2119 terms that we were using (SHOULD+, MUST-, etc) (ii)
>>>> Change the tone of the draft so that its more like best practices rather
>>>> than a diktat for protocol developers.
>>>>
>>>> Additionally, we have also included a small section on RIPng and OSPFv3
>>>> in this draft.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-bhatia-manral-igp-crypto-requi
>>>> rements-03.txt
>>>>
>>>> Would appreciate comments and feedback on the version!
>>>>
>>>> Cheers, Manav
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]]
>>>>> On Behalf Of Joel Jaeggli
>>>>> Sent: Saturday, October 11, 2008 2.40 AM
>>>>> To: opsec wg mailing list
>>>>> Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00
>>>>>
>>>>> We have at least some supporting opinion that this work should not be
>>>>> pursued in opsec if it defines requirements. With a recommendations or
>>>>> best practices focus it would be an appropriate addition. We should be
>>>>> willing to entertain alternative views but I think that's the
>>>>> current sense.
>>>>>
>>>>> joelja
>>>>> _______________________________________________
>>>>> OPSEC mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/opsec
>>>>>
>>>> _______________________________________________
>>>> OPSEC mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/opsec
>>>>
>>> _______________________________________________
>>> OPSEC mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/opsec
>>>
>>
>> _______________________________________________
>> OPSEC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsec
>>
>
_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec