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

[Gregory Lebovitz <[e-mail]>]

all the below changes indicated, plus the editorial suggestions indicated in
Magnus' Mar 05 email, are included in -03, which I'll publish shortly. See
comments inline...

On Mon, Mar 8, 2010 at 11:35 PM, Magnus Nyström <[e-mail]> wrote:

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

done


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

done


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

No change made.

Gregory.



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