Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2

Nico Williams <> Thu, 14 April 2011 17:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 693D6E0766 for <>; Thu, 14 Apr 2011 10:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.557
X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4Lq7kcZbwGJ5 for <>; Thu, 14 Apr 2011 10:06:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6985EE0663 for <>; Thu, 14 Apr 2011 10:06:15 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 6835843807C for <>; Thu, 14 Apr 2011 10:06:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s=; b=Fz/hIlbkD9eMBsPGf81kRGDJM0LjpMdEDvqQHw3I14NH e3eqOrquLn6dIvfwxMOkpe+1dtkPEx/us5JsCGKNNqAR7rm4O8Fz0wJ8fiCrEUUG wJ0/cVyFs+IK2b+abnRrNHZag/QLfW/6OOUBYG0maTAqpOZLtzVGuGMj5vPLacw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=0CqJs7ID325ZrQhVJGtSgRYgbqE=; b=mgA/0J4NFDr 8c/lLZz2dCPGWWz8Py2Bdd/MtAGTGN5iTFnJZvXxC4Pl/OVpYb2Ab45hiJwlsDut 3V9jkPcPgz2MRrFmic0M9BaXea0q2Zd0suNIKhdRUPNGIER4XnR8jVrWfr6XhVrt Rf6q48TqzaCln5vIbMsvSbAdjYrznHHw=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 350EA43806C for <>; Thu, 14 Apr 2011 10:06:14 -0700 (PDT)
Received: by vws12 with SMTP id 12so1852983vws.31 for <>; Thu, 14 Apr 2011 10:06:13 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id eq8mr1392041vdc.214.1302800773592; Thu, 14 Apr 2011 10:06:13 -0700 (PDT)
Received: by with HTTP; Thu, 14 Apr 2011 10:06:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 14 Apr 2011 12:06:13 -0500
Message-ID: <>
From: Nico Williams <>
To: Paul Hoffman <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Apr 2011 17:06:16 -0000

On Thu, Apr 14, 2011 at 11:56 AM, Paul Hoffman <> wrote:
> On Apr 14, 2011, at 9:29 AM, Nico Williams wrote:
>> On Thu, Apr 14, 2011 at 11:00 AM, Paul Hoffman <> wrote:
>>> On Apr 14, 2011, at 8:38 AM, Nico Williams wrote:
>>>> Of course, PACE is targeting Experimental... do we care about
>>>> cryptographic issues in Experimental RFCs?  I'd say we should, though
>>>> less so than for Standards Track RFCs since we can only spare so much
>>>> energy.
>>> If we "care about" such things, they should be discussed on open mailing lists, particularly if you are criticizing academic publications related to the document.
>> I'm not sure what you mean.
> I mean that the closed secdir mailing list is not an appropriate place to be discussing proposed problems with crypto protocols if the intended result is that they protocols will change or that serious design discussions happen.

It is not closed:

I remember the secdir meeting where opening the archives (though not
past archives) was decided :)

>>>> I'm rather disappointed to see this wheel reinvented.  SCRAM (RFC5802)
>>>> would fit right in instead of PACE, for example, and has the same
>>>> kinds of properties as PACE, but with a number of advantages over PACE
>>>> (SCRAM is on the Standards Track, received much more review, uses a
>>>> PBKDF with salt and iteration count, is implemented, is reusable in
>>>> many contexts, does channel binding, there's an LDAP schema for
>>>> storing SCRAM password verifiers, ...).
>>>> We, secdir, should be encouraging wheel reuse wherever possible over
>>>> wheel reinvention.
>>> "We" never have encouraged that. Many of "us" are chairs of WGs whose charters explicitly allow or mandate the opposite of what you are proposing. If you want a change, it has to come from the ADs, not from "us".
>> "We", secdir, are volunteers.  This volunteer would rather avoid wheel
>> reinvention, and this volunteer, perhaps naively, had hoped others
>> would agree.  Perhaps other volunteers disagree (you do).  I
>> explicitly referred to secdir, not WG chairs, not ADs, nor did I refer
>> to actual current practice, but rather stated an opinion of what we
>> ought to do.
> Most people on secdir are here because they are chairs of WGs in the Security Area. Maybe you are thinking of the old secdir model. :-)

Perhaps I don't belong here any longer then?  And yes, I'm thinking of
the old secdir model.  When was it abandoned?  (We both seem to be out
of date then regarding secdir practices!)

>> All that aside, is it really the case that "we" (secdir) don't mind
>> the lack of salting?  Really?!  In 2011, four decades or so since the
>> invention of salting?
> I read the paper in the PACE document and thought that it covered the design well. I even looked for follow-ups to the paper and found none (although some may have appeared since I looked). Maybe I'm naive, but I tend to assume that academic review of crypto papers on which there is also discussion in IETF WGs is sufficient for publishing something as an Experimental RFC.

It may be sufficient, but nothing says that having had WG review no
further review is applicable, even for an Experimental RFC (for
example, the IESG can always issue a do-not-publish request to the
RFC-Editor, even if the I-D in question received WG review and passed

>> Or did you really just mean to criticize me for
>> not cc'ing the IPsec list on my reply?
> No. If I meant to do that, I would have. This proposal has already been discussed in the WG for a bit over a year.

The whole point of secdir review (and IETF review) is to catch things
that might not have been caught within a WG.  Forgive me for being
late to this party, but here I am.