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

[Paul Hoffman <[e-mail]>]

On Apr 14, 2011, at 9:29 AM, Nico Williams wrote:

> On Thu, Apr 14, 2011 at 11:00 AM, Paul Hoffman <[e-mail]> 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.

> I cc'ed all, and reviewers are supposed
> to cc authors, so the authors should have a copy of my reply.  

That is not an open discussion, that forces people who are not on this mailing list to go through intermediaries.

> Also,
> over on the IPsec list we've been discussing password-based mechanisms
> (though not this one, yet, because I didn't know it was progressing so
> fast).  Since I just became aware of these issues as a result of a
> secdir posting, that's where I replied.

No problem there: I was discussing what "we" should do if "we" want discussions to have results.

> Are you suggesting that secdir reviews should always be cc'ed to the
> lists where the I-Ds in question were first reviewed?  Or that
> responders to secdir reviews should do so?  Did I do something wrong?
> Really?

No, no, no, and no.

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

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

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

--Paul Hoffman