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

From: Magnus Nyström <[email-masked]>
Date: Fri, 5 Mar 2010 21:42:59 -0800

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.

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.

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

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

Editorial:

Section 1:

- "between to endpoints" - "between two endpoints"?

Section 3.1.1:

- "fixed-length output lengths" -> "fixed-length output"?

Section 3.2.1:

- "will be that has" -> "will be that"?

-- Magnus

---

From: Magnus Nyström <[email-masked]>
Date: Mon, 8 Mar 2010 22:35:03 -0800

Thanks Gregory - a couple of comments below, inline.

On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz <[email-masked]> wrote:
> Hey Magnus,
> Thanks a lot for the review. Comments inline below...
>
> On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nyström <[email-masked]> wrote:
>>
> Ok
> 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.

> 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

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 8 Mar 2010 21:52:35 -0800

Hey Magnus,

Ok

> - "between to endpoints" - "between two endpoints"?

good catch

> - "fixed-length output lengths" -> "fixed-length output"?

good one

> - "will be that has" -> "will be that"?

got it.

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

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 8 Mar 2010 22:59:36 -0800

> I think that would be better, keeping all security considerations in

That's a fine idea. I'll do that.

> this... OK, since Pasi and Tim chose it I will rest my case...

Thanks.
Gregory.

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 24 Mar 2010 01:12:31 -0700

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

> >> requirements on future algorithms. IMO, it should.

done

> I think that would be better, keeping all security considerations in

done

> > Any thoughts from Tim or EKR?

No change made.

Gregory.

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