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: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <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