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

[Gregory Lebovitz <[e-mail]>]

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.



>
> - 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.


>
> - 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?


>
> Editorial:
>
> Section 1:
>
> - "between to endpoints" - "between two endpoints"?
>

good catch


>
> Section 3.1.1:
>
> - "fixed-length output lengths" -> "fixed-length output"?
>

good one


>
> Section 3.2.1:
>
> - "will be that has" -> "will be that"?
>

got it.

Thanks a ton again, Magnus. Good read. Much appreciated,
Gregory



>
> -- Magnus
>



-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks