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

Gregory Lebovitz <gregory.ietf@gmail.com> Tue, 09 March 2010 06:59 UTC

Return-Path: <gregory.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511DC3A6890; Mon, 8 Mar 2010 22:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.155
X-Spam-Level:
X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9fBEkZ2fPLG; Mon, 8 Mar 2010 22:59:37 -0800 (PST)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 6E82A3A6407; Mon, 8 Mar 2010 22:59:36 -0800 (PST)
Received: by bwz22 with SMTP id 22so269915bwz.28 for <multiple recipients>; Mon, 08 Mar 2010 22:59:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=R18/AjfioGTe34NIwCbox+8ckJNZ2vc70UEYX8VJvns=; b=BOwVB/+J0ddgKVERMtm+bhStID0m4bJDjy/D6jDdgDiraEhgHjtfaEnph2U3tCOmX3 nfGx7wOQDy3DDBX6nHtHZ9rC8s9E6hXA3+kqF12ZpZOAZcu/TRI3TA2lkzjZEOzZmP4r 4QY84YkDbXIY7o5GnG7U/qt4y5kg7oVv/g2zI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cAX0dm1gb2lxuvWb+QNDRwh0Sd7zoAJAvc7IDNpetP4utCioE78BHtJjn3OF9tCa7B 3EowvxNVT5CSrkz6EdrWQYOBIfHWJV/akkkzCuGjuNueiIW1YwxdknN+YPzk6eUUuECu Lp96EmbnS+fA3fc1kGqlo5GxkOcOsgx/Y8mxU=
MIME-Version: 1.0
Received: by 10.204.138.212 with SMTP id b20mr2459205bku.63.1268117976667; Mon, 08 Mar 2010 22:59:36 -0800 (PST)
In-Reply-To: <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com>
References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> <f1548841003082152j6355efc9kcc6a259c8ddb15a6@mail.gmail.com> <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com>
Date: Mon, 8 Mar 2010 22:59:36 -0800
Message-ID: <f1548841003082259i26d17ce9x487a4cdc705d7c74@mail.gmail.com>
From: Gregory Lebovitz <gregory.ietf@gmail.com>
To: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
Content-Type: multipart/alternative; boundary=001517479186885971048158b965
X-Mailman-Approved-At: Mon, 08 Mar 2010 23:53:50 -0800
Cc: magnus.westerlund@ericsson.com, Eric Rescorla <ekr@rtfm.com>, secdir@ietf.org, Tim Polk <tim.polk@nist.gov>, iesg@ietf.org, lars.eggert@nokia.com
Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2010 06:59:38 -0000

On Mon, Mar 8, 2010 at 10:35 PM, Magnus Nyström <magnusn@gmail.com> wrote:

> Thanks Gregory - a couple of comments below, inline.
>
> On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz <gregory.ietf@gmail.com>
> wrote:
> > Hey Magnus,
> > Thanks a lot for the review. Comments inline below...
> >
> > On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nyström <magnusn@gmail.com>
> 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.
>

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


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

Thanks.
Gregory.



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



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