Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-02
Gregory Lebovitz <gregory.ietf@gmail.com> Wed, 24 March 2010 08:12 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 9B7BA3A68F6; Wed, 24 Mar 2010 01:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.075
X-Spam-Level:
X-Spam-Status: No, score=-98.075 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 qTkn65MvhfPN; Wed, 24 Mar 2010 01:12:20 -0700 (PDT)
Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id EF13D3A6C71; Wed, 24 Mar 2010 01:12:13 -0700 (PDT)
Received: by iwn35 with SMTP id 35so4608119iwn.31 for <multiple recipients>; Wed, 24 Mar 2010 01:12:31 -0700 (PDT)
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=0JOQBjRM6WMPD3rGvAdG9rpsbaE0017fHQq0eciWK68=; b=kL4AlW/xAlr3RQxFLBTZpqh/TCLu/pe5QYiD8y2kNtAm49LSF8/BW7PBeuzZRL6CUJ kyeSSZXl7WqvQ9ISHjiFxsLgJfCRuDp+bQHQ05bBQK/xxxNR01YAds55/riFC5TdGFet AJatpsJ8Uv49fbrxzOBzYBfekUcHQmzgUyF1Y=
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=TilXYNmaIOuDnClFMygvbJ29+7wqUL+ZIYoFkgmvCjZHeHpXpi6XrNjLb/vYnCUU0U hAy5EeSNHq+vOMjoRfYSmNMl/X6sQNAbpmcfJweFg6ibuJxa2tQ7V75VtHz54xOKrG63 744eeZLp6Q0meR4DBxsJ6V0u+0yYgO8rr4PvA=
MIME-Version: 1.0
Received: by 10.231.169.144 with SMTP id z16mr1520599iby.25.1269418351280; Wed, 24 Mar 2010 01:12:31 -0700 (PDT)
In-Reply-To: <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com>
References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> <f1548841003082152j6355efc9kcc6a259c8ddb15a6@mail.gmail.com> <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com>
Date: Wed, 24 Mar 2010 01:12:31 -0700
Message-ID: <f1548841003240112p10d7f0bbiffedfb2de6267615@mail.gmail.com>
From: Gregory Lebovitz <gregory.ietf@gmail.com>
To: Magnus Nyström <magnusn@gmail.com>
Content-Type: multipart/alternative; boundary="0016e6d26c5ae642ba0482877d85"
Cc: magnus.westerlund@ericsson.com, Eric Rescorla <ekr@rtfm.com>, tcpm@ietf.org, 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: Wed, 24 Mar 2010 08:12:22 -0000
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 <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 > 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
- [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