Re: [Cfrg] Requesting removal of CFRG co-chair

[Trevor Perrin <[e-mail]>]

Hi David,

(trimming recipients back to CFRG list)

On Mon, Dec 23, 2013 at 9:14 PM, David McGrew <[e-mail]> wrote:
>
>
> On 12/20/2013 11:01 AM, Trevor Perrin wrote:
>>
>> Dear IRTF Chair, IAB, and CFRG:
>>
>> I'd like to request the removal of Kevin Igoe from CFRG co-chair.
>>
>> The Crypto Forum Research Group is chartered to provide crypto advice
>> to IETF Working Groups.
>
>
> CFRG is chartered to "provide a forum for discussing and analyzing general
> cryptographic aspects of security protocols, and to offer guidance on the
> use of emerging mechanisms and new uses of existing mechanisms." The charter
> also says that "IETF working groups developing protocols that include
> cryptographic elements are welcome to bring questions concerning the
> protocols to the CFRG for advice." The wording of this charter was carefully
> chosen so as to not compete with IETF standards activities in crypto; note
> that an IETF Working Group only gets advice if they ask for it. (They don't
> ask often.)

Would you agree that CFRG's charter includes providing crypto advice
to IETF WGs, and that this advice is an important output from CFRG?


>> As CFRG co-chair for the last 2 years, Kevin
>> has shaped CFRG discussion and provided CFRG opinion to WGs.
>
>
> You say "Working Groups" in the plural. To what IETF Working Group, other
> than TLS, do you think that Kevin has represented the CFRG collective
> opinion?

I was thinking of TLS.  Kevin has provided advice to other groups
(HIP, JOSE), but I don't know whether that was construed as coming
from CFRG or Kevin.


>> Kevin's handling of the "Dragonfly" protocol raises doubts that he is
>> performing these duties competently.
>
>
> No standards process is ever perfect, and CFRG is an IRTF Research Group,
> not an IETF Working Group. As such, it has a less formally defined process.
> You have a right as an RG member to ask how your opinion as an RG member is
> being included in the summary of the RG opinion.

Yes, I've asked why it was reported to TLS WG that CFRG approved of
Dragonfly, despite the record reflecting skepticism:

http://www.ietf.org/mail-archive/web/cfrg/current/msg03545.html


> As far as Kevin's
> competence goes, your complaint needs to be balanced against his
> contributions.

I've looked over his mailing list contributions.

Kevin seems unfamiliar with sidechannel attacks, RSA padding, provable
security, key agreement protocols, and consulting academic literature.
 I'm sure he's good at math, but I don't see the breadth of knowledge
I'd expect for his position.

His messages don't reflect a high standard of diligence.  He's made
significant mistakes with Dragonfly.  His tone reminds me of a bemused
hobbyist who doesn't care whether any of this is secure.

I believe there are people who could do a better job.


>> Additionally, Kevin's employment
>> with the National Security Agency raises conflict-of-interest
>> concerns.
>
>
>
> One of the main challenges that CFRG has faced over the years has been that
> of getting sustained, ongoing participation. CFRG is a volunteer
> organization, and as such it relies on professionals that are willing and
> able to contribute their time. It is easy to get people to agree that
> "something should be done", but getting individuals to contribute on an
> ongoing basis has been difficult.

Having seen how CFRG contributions are ignored by the chairs, I'm not
surprised people aren't interested in contributing.


> There are far more people active on this
> thread than people who are actively contributing to the RG as authors and
> reviewers of internet drafts. It would be great if we could have more
> regular participation from academics, but in the past it has not proven
> possible. (In particular, a professor is likely to have a hard time
> justifying the ongoing commitment of being a co-chair.) Since CFRG does not
> author standards, it is less appealing to vendors as a place to engage. It
> is not surprising that someone from an intelligence agency that is tasked
> with communication security has the qualifications and can justify the time
> commitment.

Has there ever been an open process for CFRG chairs?  I think you and
Ran Canetti were appointed at the beginning of CFRG, and then you
appointed Kevin as Ran's replacement with no call for other
candidates.  Is that right?

You seem to be arguing that intelligence agencies are the only people
who would propose someone for CFRG chair.

I'm not sure that's true.  Perhaps CFRG should follow an actual
process for selecting its chairs.  Kevin or anyone else would be
welcome to participate.


> I assume that you would oppose a CFRG chair that was an employee of any
> government communication security agency, for any government, and presumably
> a contractor for one as well. Is that right?

No, if I trusted that the "government communications security agency"
was actually working to provide "communications security" instead of
intelligence access.

It's difficult to ascertain that, of course.  Some uncertainty and
angst will attend any decision we make.  That's life in crypto.

Still, we should do the best we can to select a chair who is trusted
and respected by a wide audience.  At the current moment, I believe
that means avoiding the NSA.


> What about someone in the role
> of a document author or co-author? Would you ask that Sean Shen step down as
> co-author of draft-irtf-cfrg-cipher-catalog-01, for instance? I hope not,
> but these are important questions to consider.

No one proposed that.

It's easy to scrutinize the work of a document author.

In contrast, the IETF/IRTF's lack of formal process places a lot of
power in the chair.  The chair has the ability to call consensus,
communicate this to other groups, and has "wide discretion in the
conduct of Research Group business" [1].  For the CFRG chairs this has
included handling an important security flaw prior to public
disclosure [2].

Even if we detect incorrect behavior from a chair, trying to challenge
it is hard and disruptive (see Dragonfly).

The competence and judgement of a chair, and his/her ability to
inspire trust, is very important to a successful WG or RG.


>> Dragonfly Background
>> ----
>> Dragonfly is a "Password-Authenticated Key Exchange" protocol (or
>> "PAKE").  Dragonfly was proposed to CFRG 2 years ago [PROPOSAL].
>> Compared to better-known PAKEs, Dragonfly has no security proof, a
>> lack of extensive security analysis, nonfunctional complications added
>> for IPR reasons, and some security issues [REVIEW].
>>
>> Dragonfly became a hot topic recently when the TLS WG disputed CFRG's
>> alleged report that Dragonfly was "satisfactory", as well as disputing
>> that this report reflected CFRG consensus [TLS_1].  After extensive
>> criticism of Dragonfly, the TLS WG ceased work on a Dragonfly
>> extension [TLS_2].
>
>
> If you feel that some other PAKE protocol would be better than Dragonfly,
> let me ask: have you considered authoring an Internet Draft that compares
> different PAKE protocols?

I've considered it.  But I won't contribute to this group under NSA leadership.


>> Reasons for requesting Kevin's removal
>> ----
>> 1)  Kevin has provided the *ONLY* positive feedback for Dragonfly that
>> can be found on the CFRG mailing list or meeting minutes.  The
>> contrast between Kevin's enthusiasm and the group's skepticism is
>> striking [CFRG_SUMMARY].  It's unclear what this enthusiasm is based
>> on.  There's no record of Kevin making any effort to understand
>> Dragonfly's unusual structure, compare it to alternatives, consider
>> possible use cases, or construct a formal security analysis.
>>
>> 2)  Twice Kevin suggested a technique for deriving the Dragonfly
>> password-based element which would make the protocol easy to break
>> [IGOE_1, IGOE_2].
>
>
> [IGOE_2] ends with the statement "Many thanks to Rene Struik and Scott
> Fluhrer for their insightful comments. Would anyone else on the list like to
> join in? We can’t learn from our mistakes until we realize we’ve made them."
> I have a hard time seeing this message as steering the RG in an unfruitful
> direction.

That's [IGOE_3].  See the paragraph preceding your quote.  "steering
the RG in an unfruitful direction" is exactly how I'd describe it.


>> He also endorsed an ineffective attempt to avoid
>> timing attacks by adding extra iterations to one of the loops [IGOE_3,
>> IGOE_4].
>
>
> I think that by "ineffective attempt to avoid timing attacks" you are
> referring to your statement that "within each loop are conditional branches
> and Legendre symbol / square-root algorithms, which are hard to implement
> efficiently in constant time ([STRUIK], [ICART], [FIPS186-4])" from
> [REVIEW]. Is this right? There is a significant difference between "hard to
> implement" and "ineffective". The statement in [REVIEW] makes it sound like
> it is inconvenient for the implementer, while the statement in your email
> makes it sound as though it is impossible.

Not sure I understand this quibble.

I believe there's a serious timing attack risk in the CFRG and TLS
Dragonfly drafts, as has been explained repeatedly by many people.


>> These are surprising mistakes from an experienced
>> cryptographer.
>>
>> 3)  Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG
>> consensus, which was skeptical of Dragonfly [CFRG_SUMMARY].
>>
>> 4)  Kevin's NSA affiliation raises unpleasant but unavoidable
>> questions regarding these actions.  It's entirely possible these are
>> just mistakes by a novice chair who lacks experience in a particular
>> sort of protocol and is being pressured by IETF participants to
>> endorse something.
>
>
> Yes, I agree: It's entirely possible these are just mistakes by a novice
> chair who lacks experience in a particular sort of protocol and is being
> pressured by IETF participants to endorse something.

I think CFRG deserves a chair who would be informed enough to
understand these areas, and diligent enough not to make the technical
and process mistakes that Kevin did.


> I am concerned that many of the people who are arguing the most against
> Kevin continuing as CFRG co-chair have not previously participated in CFRG.
> I hope that they stay and participate over the long run, and are willing to
> review and contribute to drafts, meetings, and discussions on the mail list.
> But it would not be healthy for the IRTF if an influx of temporary members
> could have a disruptive effect.

CFRG's crypto advice has wide consequences.  It's reasonable to
consider feedback from outside the club of IETF crypto gurus.

Anyways, I'll be stepping away for a few days as well, happy holidays everyone.


Trevor


[1] http://wiki.tools.ietf.org/html/rfc2014#section-5.3
[2] Lucky 13 - http://www.isg.rhul.ac.uk/tls/TLStiming.pdf