Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

[Stephen Farrell <[e-mail]>]

On 21/05/14 09:07, Bhatia, Manav (Manav) wrote:
> Stephen,
> 
>>> The Apad is now employed for RIP, OSPF, OSPFv3. I see no reason
>>> why LDP should be an exception. The same has been proposed for
>>> BFD btw.
>> 
>> Even given the above, I fail to see why you repeat this text over 
>> and over and over. Is there a real logic for that?
> 
> Yes. The logic is that Apad keeps changing based on the protocol.
> There are some specific attacks that can be prevented by defining
> Apad to mean something specific. In case of OSPFv2 it means the
> source address of the sender. In case of OSPFv3, it is a value where
> the first 16 octets contain the IPv6 source address followed by the
> hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. L in this case
> is the length of the hash.
> 
> In case of RIpv2 and IS-IS it's a fixed constant.
> 
> In this draft Apad is defined as:
> 
> In case of IPv4, the first 4 octets contain the IPv4 source address
> followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times.
>  In case of IPv6, the first 16 octets contain the IPv6 source address
> followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4
> times.
> 
> One way to avoid this duplication is by writing a new RFC that
> redefines HMAC and includes the Apad. Other documents can only
> mention the Apad value, while including a normative reference to that
> RFC.
> 
> This however is a long drawn discussion because everyone needs to be
> convinced on the merits of updating the HMAC specification -- which I
> am not sure will take how long.

So I need to look at this draft, HMAC and the other cases but
it seems to me that you're copying a page or two of crypto
spec each time and changing one line. Doing that over and over
is a recipe for long term pain, isn't it?

(And we've had this discussion for each such draft while I've
been on the IESG I think, which is also somewhat drawn out;-)

S.


> 
> Cheers, Manav
> 
> 
>> 
>> S
>> 
>>> 
>>> Cheers, Manav
>>> 
>>>> -----Original Message----- From: Stephen Farrell 
>>>> [mailto:[e-mail]] Sent: Wednesday, May 21,
>>>> 2014 2:53 AM To: Bhatia, Manav (Manav); IETF Security
>>>> Directorate; The IESG; draft-
>>>> [e-mail] Cc: Yaron
>>>> Sheffer; [e-mail] Subject: Re: SecDir review of 
>>>> draft-ietf-mpls-ldp-hello-crypto-auth-05
>>>> 
>>>> 
>>>> 
>>>> On 19/05/14 21:27, Yaron Sheffer wrote:
>>>>>>> 
>>>>>>> * 5.1: Redefining HMAC (RFC 2104) is an extremely bad
>>>>>>> idea. This reviewer does not have the appropriate
>>>>>>> background to critique the proposed solution, but there
>>>>>>> must be an overwhelming reason to
>>>> reopen> >>>>> cryptographic primitives.
>>>>>> 
>>>>>> This is a decision that was taken by Sec Ads when we were
>>>>>> doing the crypto protection for the IGPs based on some
>>>>>> feedback from NIST.
>>>> This
>>>>>> mathematics is not new and has been done for all IGPs and
>>>>>> has been approved and rather encouraged by the Security
>>>>>> ADs.
>>>> 
>>>> The above does not sound like something I recognise. I have 
>>>> repeatedly asked that documents not re-define HMAC. Perhaps
>>>> this time, I'll make that a DISCUSS and not budge. I probably
>>>> should have done that before TBH.
>>>> 
>>>> If you are revising that doc, *please* get rid of the
>>>> re-definition and just properly refer to HMAC. Its about time
>>>> to stop repeating that error.
>>>> 
>>>> S.
>>> 
>>> 
>>> 
> 
> 
>