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

[David McGrew <[e-mail]>]

Hi Trevor,

On 12/24/2013 07:02 AM, Trevor Perrin wrote:
> 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?

Yes, but I felt that I needed to clarify how this guidance fits into the 
IETF process, as there are people participating on this thread that are 
new to the IRTF.

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

I respectfully disagree with your characterization.   I would guess that 
if you could have been present for the discussion at the RG meeting, you 
might feel differently.

Let me make an aside about provable security. In the crypto practice 
community, it is often regarded as oversold.  A proven-secure protocol 
is only secure in the real world if it uses an attack model and a set of 
premises and assumptions that are completely accurate.    Consider, for 
example, that a provably-secure nonce-based encryption scheme looks 
great from a theory perspective, but if you use it in a real-world 
situation in which it is difficult to ensure that nonces are actually 
distinct, then the actual security stinks.   The practice community 
sometimes hears claims that a protocol that was proven secure (in one 
model) has been broken (in another model), and this seeming 
contradiction undermines some of the confidence in provable security.  
Considering that CFRG aims to be a bridge between practice/standards and 
theory, I would like to encourage the discussion on provable security to 
go into the model and assumptions.   This will be the best way to ensure 
that the practitioners understand the relevance of a security proof, and 
for the theory people to sanity-check their assumptions and model with 
the practitioners where appropriate (as in the nonce example above).

We *should* encourage the practice community to use proven-secure 
protocols where possible - but we should also understand that much of 
that community has skepticism.   For perspective, we should realize that 
many in the practice community resist the deprecation of ciphers that 
are in the field, or in extant standards, until the attacks against them 
are downright easy; RC4 and 3DES are recent examples.   This community 
has the opinion that they do not need to replace ciphers that are not 
currently breakable with commonly available resources.  I disagree with 
this opinion, of course, but I bring it up to emphasize the need for 
CFRG to engage constructively with these folks, who place far less value 
on provable security than the theory community does.

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

Ran Canetti and I formed CFRG by following the process described in RFC 
2014:

                                  Anyone interested in creating an
    IRTF Research Group must submit a charter for the proposed group to
    the IRTF Chair along with a list of proposed founding members.  The
    charter will be reviewed by the IRSG and then forwarded to the IAB
    for approval.  If approved, the charter is placed on the IRTF Web site, and
    published in the Internet Monthly Report (IMR).


When Kevin joined as co-chair, the only public process was an 
affirmation.   There was not a public call for a co-chair; this is not 
unusual for an IRTF Research Group.   I did have private discussions 
with a bunch of potential co-chair candidates at the time.   I cannot 
recall anyone expressing any reservations about Kevin at the time, 
either publicly or privately.


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

I agree that it is not true; it is an overstatement.  But it is a fact 
that intelligence agencies have a lot of the talent that will show up at 
a venue like this, and that those organizations are able to justify the 
cost of ongoing professional participation.

> Perhaps CFRG should follow an actual
> process for selecting its chairs.  Kevin or anyone else would be
> welcome to participate.

Do I understand you correctly to say that you would accept Kevin as a 
co-chair if he was selected through some sort of official process, other 
than affirmation by the RG?

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

Agreed on the uncertainty.

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

I didn't mean to suggest that you said that, but I did want to ask. If 
the IRTF decides to establish a policy that is based on an RG member's 
employer, as you are advocating, it would be best to establish the 
entire policy up front, rather than debate each case as it comes up.

If the IRTF does set a "no NSA" policy, it needs to be consistent and 
set a "no intelligence agency" policy.   I strongly suspect that what is 
unique about the NSA is not what they are doing, but rather the fact 
that some of their goals and means have been exposed.   And perhaps the 
scale of their activities as well, but then again, its is hard to assess 
the scale of the SIGINT activities of the world governments for 
comparison.   The IETF and the CFRG need to be wary about crypto designs 
regardless of their sources.

If we really did want to exclude people from intelligence agencies while 
not setting a formal policy to that effect, we could achieve that goal 
by crafting a policy that demands more transparency than an intelligence 
agency would be comfortable with.   For instance, the policy could 
require the publication of all of the contributor's publications, 
regardless of whether or not they have been classified, or it could 
require that the contributor sign a statement regarding transparency 
that their employer would never agree to.   But note that if we did 
this, it would not solve any problems, because an intelligence agency 
could always work through contractors or other people who are on their 
payroll, but do not admit to being on their payroll.

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

Agreed.

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

That's a fair point.

>   For the CFRG chairs this has
> included handling an important security flaw prior to public
> disclosure [2].

What do you mean by this?   Are you saying that the CFRG chairs 
mishandled the Lucky-13 disclosure?   If so, I strongly disagree. Kenny 
managed that disclosure (and deserves kudos for his contributions to 
CFRG and the IETF), and Kevin and I had the role of explaining the 
seriousness of the attack to the TLS WG chairs and Security Area 
Directors, all of which happened through private communications rather 
than on-list communications, of course.   But I suspect that I don't 
understand your point here.

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

I am sorry to hear this; drafts are the official documents of the RG, 
and we can only make progress through well-written and well-reviewed 
contributions.   Perhaps you could ask the Security Area Directors if 
you could author an individual submission in that area, if you think 
that is a better idea.   (They may not like the idea, but you could ask.)

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

If I understand you, the paragraph is Kevin's summary of Scott's 
improvement to Dan's protocol.   To me, that paragraph, followed by the 
request for review, looks like an RG chair that is seeking to stimulate 
discussion.

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

The important point here is that a Research Group chair reading [REVIEW] 
could get the impression that the proposed mitigation to timing attacks 
is "hard to implement" rather than "ineffective", in your opinion.

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

Of course we need informed and diligent chairs.   But when we are 
establishing the criteria that we expect from the CFRG chairs, we need 
to keep in mind that the higher that we set the bar, the fewer the 
candidates that will be qualified and interested.   It would be wrong to 
set an expectation that each email that attempts to summarize the 
on-list discussion must be free from flaws, for instance.

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

Absolutely, feedback and input is welcome.

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

Happy holidays to you and everyone else celebrating at this time.

David

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