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

[David McGrew <[e-mail]>]

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

> 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. As far as Kevin's competence goes, your complaint needs to be 
balanced against his contributions.

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

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

>
> 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? You could take the approach of 
authoring an individual submission, which represents your point of view, 
or you could aim to author a draft that represents the consensus 
viewpoint of the entire research group. A good approach might be to 
write up an individual submission, then aim to convince the RG that it 
should be the consensus opinion. If there is a significant body of 
people who disagree, then the appropriate procedure is to document the 
disagreement as honestly as possible.

As you noted, there have been other PAKE proposals. I am fine with 
having the research group review more of these proposals, either on the 
list or at the next meeting. (As a side note: I am lukewarm about the 
usefulness of these protocols, because they only prevent offline 
dictionary attacks, and not online dictionary attacks, and they do 
nothing to prevent non-cryptographic attacks that steal or guess 
passwords. The non-cryptographic attacks are, in practice, a bigger 
threat than the cryptographic attacks. So what would be the best 
contribution in the PAKE area, in my opinion, is guidance on the usage 
and limitations of PAKE protocols in general.)

>
>
> NSA Background
> ----
> The National Security Agency ("NSA") is a U.S. Intelligence Agency
> which is believed to devote considerable resources to:
>   - "Influence policies, standards and specifications for commercial
> public key technologies"
>   - "Shape the worldwide cryptography marketplace to make it more
> tractable to advanced cryptanalytic capabilities" [BULLRUN]
>
> While much is unknown about these activities, the NSA is known to have
> placed a "back door" in a NIST standard for random number generation
> [ECDRBG].  A recent report from the President's Review Group
> recommends that the NSA:
>   - "fully support and not undermine efforts to create encryption standards"
>   - "not in any way subvert, undermine, weaken, or make vulnerable
> generally available commercial software" [PRESIDENTS]
>
> This suggests the NSA is currently behaving contrary to the recommendations.
>
>
> 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.

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

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

>   But it's hard to escape an impression of
> carelessness and unseriousness in Kevin's work.  One wonders whether
> the NSA is happy to preside over this sort of sloppy crypto design.
>
> While that's of course speculation, it remains baffling that an
> experienced cryptographer would champion such a shoddy protocol.  The
> CFRG chairs have been silent for months, and haven't responded to
> attempts to clarify this.
>
>
> Conclusion
> ----
> The position of CFRG chair (or co-chair) is a role of crucial
> importance to the IETF community.  The IETF is in desperate need of
> trustworthy crypto guidance from parties who are above suspicion.  I
> encourage the IAB and IRTF to replace Kevin Igoe with someone who can
> provide this.
>
> Thanks for considering this request.


I asked Kevin to become a co-chair back in 2011, at which time I was the 
only chair of the RG. I had worked with him on some internet drafts, and 
had a great respect for his understanding of both the theory and the 
practice of cryptography, and understanding both areas is important for 
the RG. It is important to have more than one chair, otherwise the 
single chair should not be acting as a co-author in the RG. My opinion: 
I have not seen Kevin subvert any process, and for that matter, I don't 
think RG chairs are well positioned to subvert standards processes.

It is important that the Research Group have chairs that it trusts. It 
is also an important principle at IETF and IRTF that people who 
participate do so as individuals and not as representatives of their 
employers (which is stated in sentence five at irtf.org). Lars, the IRTF 
Chair, along with the IAB, will need to balance those two considerations.

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.

David

In case anyone wants to know: I have never worked for any government or 
held any security clearance.

>
> Trevor
>
>
> [PROPOSAL]http://www.ietf.org/mail-archive/web/cfrg/current/msg03044.html
> [REVIEW]http://www.ietf.org/mail-archive/web/cfrg/current/msg03537.html
> [TLS_1]http://www.ietf.org/mail-archive/web/tls/current/msg10819.html
> [TLS_2]http://www.ietf.org/mail-archive/web/tls/current/msg10993.html
> [BULLRUN]http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html
> [ECDRBG]http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/
> [PRESIDENTS]http://www.whitehouse.gov/sites/default/files/docs/2013-12-12_rg_final_report.pdf
> [CFRG_SUMMARY]http://www.ietf.org/mail-archive/web/cfrg/current/msg03545.html
> [IGOE_1]http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
> [IGOE_2]http://www.ietf.org/mail-archive/web/cfrg/current/msg03258.html
> [IGOE_3]http://www.ietf.org/mail-archive/web/cfrg/current/msg03262.html
> [IGOE_4]http://www.ietf.org/mail-archive/web/cfrg/current/msg03264.html
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
> .
>