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, 08 Mar 2010 22:59:36 -0800
Message-ID: <f1548841003082259i26d17ce9x487a4cdc705d7c74@mail.gmail.com>
From: Gregory Lebovitz <gregory.ietf@gmail.com>
To: Magnus Nyström <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
- [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Gregory Lebovitz
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Gregory Lebovitz
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Gregory Lebovitz