[OSPF] FW: Gen-ART review of draft-ietf-ospf-hmac-sha-05

[Acee Lindem <[e-mail]>]

From: <[e-mail]>
Date: July 22, 2009 8:40:47 PM EDT
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Gen-ART review of draft-ietf-ospf-hmac-sha-05


Ran,

This is fine with me - about the level of requirement for
SHA-224 and SHA-384, I originally wrote:

> To avoid confusion, this is a request that the authors think
> about this topic; it is *not* a comment that the requirement
> needs to be changed.  If the authors believe that the current
> "SHOULD" requirements for these two hashes are the right
> approach, that is acceptable to me.

Thinking has clearly happened ;-), and I have no problem with
a result that that the requirement level will not be changed
because doing so would reduce consensus.

Thanks,
--David

> -----Original Message-----
> From: RJ Atkinson [mailto:[e-mail]]
> Sent: Wednesday, July 22, 2009 5:55 PM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: Gen-ART review of draft-ietf-ospf-hmac-sha-05
>
> All,
>
> On  22 Jul 2009, at 11:31, Bhatia, Manav (Manav) wrote:
>> Given that SHA-224 (and perhaps SHA-384) is not even present in all
>> crypto libraries we could, if others don't see a problem, move this
>> from a SHOULD to a MAY.
>
> All of the key-lengths for SHA-1 and SHA-2 are available in
> at least some freely available crypto libraries, specifically
> including both SHA-224 and SHA-384.
>
> (ASIDE:  Commonly used search engines can be used to find such
libraries.
> Choice of which libraries, if any, to use is obviously implementer's
choice.)
>
> Making that change to "MAY" would reduce consensus, as compared
> with retaining the current "SHOULD" text, so it is best to keep
> the current language as-is.
>
>>> In Section 3.2, it would be useful for the draft to say that an
>>> OSPFv2 Security Association is not set up inband via OSPFv2, in
>>> contrast to an IPsec Security Association created via IKE.  Among
>>
>> Yup, sounds reasonable. We could add this too.
>
> I made that edit about an hour after David's note was originally sent.
>
>>> the reasons that this should be done is that the term "OSPFv2
>>> Security Association" is introduced in this draft - that term
>>> does not occur in RFC 2328, even though Section D.3 of RFC 2328
>>> defines an abstraction for which "OSPFv2 Security Association"
>>> is an appropriate name.  I recommend stating that this term is
>>> new to this draft.
>>>
>>> The mention of IP Security in the next to last paragraph of
>>> the Security Considerations (section 4) should cite an
>>> informative reference, RFC 4301 would be appropriate.
>>>
>>
>> Yup, this can also be done.
>
> Again, I made that edit about an hour after David's note was
> originally sent.
>
> Cheers,
>
> Ran Atkinson
> (who is the active document editor for this draft)
>
>