Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-02

[Magnus Nyström <[e-mail]>]

Thanks Gregory - a couple of comments below, inline.

On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz <[e-mail]> wrote:
> Hey Magnus,
> Thanks a lot for the review. Comments inline below...
>
> On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nyström <[e-mail]> wrote:
>>
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments
>>
>> This document specifies requirements on cryptographic algorithms to be
>> used in the TCP Authentication Option (TCP APO). It also specifies
>> some mandatory algorithms.
>>
>> Comments:
>>
>> Abstract:
>>
>> - The abstract does not mention that the document also specifies
>> requirements on future algorithms. IMO, it should.
>
> Ok
>
>>
>> Section 1:
>> (- Last paragraph is what prompted my comment on the abstract.)
>>
>> Section 2.2:
>>
>> - Suggest moving the note explaining the need to mandate two MAC
>> algorithms to the Security Considerations section as it does not
>> contain normative text but does contain security considerations.
>
> Good point. When I originally wrote this text it did contain normative text.
> Then I got some feedback that maybe we should down-grade the text to be
> non-normative, but still clear guidance. If you think it makes a big
> difference, I can move it. Otherwise, I'd like to keep it with the text
> describing the "template" for how all TCP-AO algos are used, so that people
> who are looking for the template will see the text right there, whereas they
> might miss it if they are skimming and don't make it all the way to the SC
> section. Let me know what you think.

You could also place the note in the Security Considerations section
and then just reference it in 2.2, like "For an explanation of the
need for two MAC algorithms, see the Security Considerations section."
I think that would be better, keeping all security considerations in
one place.

>> - Section 3.1.1.3:
>>
>> - It is a little surprising to see that the SHA-1-based MAC algorithm
>> is selected as the default one, given that this is a new specification
>> and the industry is moving away from SHA-1. C.f. the work on XML
>> Encryption 1.1 and XML Signature 1.1 that specificallly recommends
>> against use of SHA-1 in new applications.
>
> In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not have
> the same properties in this context, and has shown no weaknesses, afaik. As
> you can imagine we had a very long debate around which algo to make
> mandatory. In the end (as the text was supposed to explain), Pasi and Tim
> chose SHA-1 for both its strength and its wide availability in the target
> devices (routers -- this is first and foremost being done for BGP
> protection). But, since it's been around a while, and we always want to have
> 2 good algos in place, one the older more available, and a newer
> up-and-comer, the AES was also specified. Unless Pasi and Tim want to change
> their recommendations to the TCPM WG, we'll probably sit tight with this the
> way it reads currently.

Yes, I can (and did...) imagine you had lengthy discussions around
this... OK, since Pasi and Tim chose it I will rest my case...

Best,
-- Magnus

>> - Section 6 (Security Considerations):
>>
>> In the fourth paragraph, there is a discussion around the fact that
>> the document does not force use of a 16 octet key. I think it would be
>> useful to at least clearly state a recommended minimum key size.
>
> Interesting point. We had this debate in WG too.
> My .02:  this is a security vs convenience thing. We give the deployer
> plenty enough guidance and pointers to other RFC's and NIST docs to allow
> them to do their homework to decide what length key they want, stopping just
> short of telling them a recommended min key size. The deployers here are
> router operators, for the most part. The ones that have a clue are already
> using 128bit keys, generated randomly. The ones that aren't probably aren't
> going to read this document anyway.
> Any thoughts from Tim or EKR?