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

From: Trevor Perrin <[email-masked]>
Date: Fri, 20 Dec 2013 08:01:38 -0800

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.  As CFRG co-chair for the last 2 years, Kevin
has shaped CFRG discussion and provided CFRG opinion to WGs.

Kevin's handling of the "Dragonfly" protocol raises doubts that he is
performing these duties competently.  Additionally, Kevin's employment
with the National Security Agency raises conflict-of-interest
concerns.

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

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].  He also endorsed an ineffective attempt to avoid
timing attacks by adding extra iterations to one of the loops [IGOE_3,
IGOE_4].  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.  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.

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

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 20 Dec 2013 16:15:34 +0000

The request to remove/replace Kevin Igoe is very strongly seconded, for all the given reasons: I would have sent a request in similar terms, had someone not done so first.

I would raise the possibility of offering the co-chair position to Bruce Schneier instead, if he is willing, and in a position to, accept.

His talk at IETF 88 was exactly the right thing, at the right time, and he is an extremely well-known and respected civilian researcher in the crypto community, as I'm sure you're aware.

- --
/akr

---

From: William Whyte <[email-masked]>
Date: Fri, 20 Dec 2013 14:04:41 -0500

I agree. It's appropriate for Kevin to be able to contribute, just as it's
appropriate for any individual to be able to contribute, but it's not
appropriate for any NSA employee to have a role of responsibility in a
crypto standards group, especially a group developing standards to be used
worldwide.

William

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of Trevor Perrin
Sent: Friday, December 20, 2013 11:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Cfrg] Requesting removal of CFRG co-chair

The Crypto Forum Research Group is chartered to provide crypto advice to
IETF Working Groups.  As CFRG co-chair for the last 2 years, Kevin has
shaped CFRG discussion and provided CFRG opinion to WGs.

Kevin's handling of the "Dragonfly" protocol raises doubts that he is
performing these duties competently.  Additionally, Kevin's employment
with the National Security Agency raises conflict-of-interest concerns.

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

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].  He also endorsed an ineffective attempt to avoid timing
attacks by adding extra iterations to one of the loops [IGOE_3, IGOE_4].
These are surprising mistakes from an experienced cryptographer.

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

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-camp
aign-against-encryption.html
[ECDRBG]
http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-res
tore-confidence-on-encryption-standards/
[PRESIDENTS]
http://www.whitehouse.gov/sites/default/files/docs/2013-12-12_rg_final_rep
ort.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
[email-masked]
http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 21 Dec 2013 00:28:09 -0800 (PST)

This request is FUD on top of innuendo.

  The protocol in question, dragonfly, does not have any security
flaws that would cause it to be inappropriate as a TLS cipher suite.
Given that Standards Track RFCs defining TLS cipher suites are
susceptible to attacks that dragonfly is provably resistant to
underscores that fact.

  The recent discussion on the TLS list actually just rehashed old
issues raised 2 years or more before the WGLC, namely:

  1) there is no security proof for resistance to an off-line
      dictionary attack; and
  2) there is text in the draft that deals with a potential side
      channel attack.

It was #1 that prompted the request to CFRG. The TLS WG did
not feel it was capable of evaluating that part of a cryptographic
key exchange and asked the CFRG to take a look. No attack
against dragonfly was brought up during the CFRG review, and
to this day there is no known attack against it.

Issue #2 is the result of a mailing list discussion prior to WGLC.
Note that Trevor  Perrin did not have an opinion on the matter when
it was discussed; he actually only commented 2+ years later, after
WGLC closed. If WG consensus wanted to re-open the issue, it might
make sense to discuss other resolutions as a way to move forward
but Trevor has stated that it doesn't matter, he will oppose the draft
no matter what changes are done.

  I am extremely sorry that my draft seems to have caused the CFRG
chairs to be the target of these accusations.

  It's always easy to be a critic and it's especially easy to launch a
FUD-based criticism. But criticizing someone who volunteers to
do work that one is not capable of doing himself is especially
lazy. The added implication of a conspiracy theory should be all
the more reason to reject it.

  There is no substance to this complaint and I hope it is
summarily dismissed.

  regards,

  Dan.

On Fri, December 20, 2013 8:01 am, Trevor Perrin wrote:
> 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]

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 21 Dec 2013 10:42:51 +0000

Hi,

> I'd like to request the removal of Kevin Igoe from CFRG co-chair.

I'd like to acknowledge the receipt of your request.

I'd also like to ask CFRG participants to discuss the arguments you are raising, and I highly appreciate that some of you have already done so on the RG mailing list. That is the best place for this discussion, but if people would like to comment in private, I can be reached at [email-masked].

Lars Eggert
IRTF Chair

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 21 Dec 2013 14:40:19 +0000

[Cross-posting ceased, in light of Lars' message: he'll read the list.]

> This request is FUD on top of innuendo.
  [...]
> The added implication of a conspiracy theory should be all the more
>  reason to reject it.

With all due respect, it is simply pointing out an elephant in the room:

• The NSA have been publicly documented, and caught, manipulating and
  subverting cryptographic standards to weaken them.

  - It is a publicly-documented fact being discussed by an oversight
    panel who are recommending that the President stop the NSA doing
    that.

  - That unavoidably logically implies that they're doing it now.

  - Not a conspiracy theory therefore: documented fact.

  - It was specifically discussed at the IETF 88 Technical Plenary.
    If you are unfamiliar with that discussion, and the resulting hums,
    please look it up. <https://youtu.be/oV71hhEpQ20?t=25m9s>

• If a nation state adversary were doing such a thing, they would
  probably target (among others) this group, which is chartered with
  evaluating cryptographic standards for internet protocols.

  - Ideally, they would hold a position of power, being able to guide
    the committees into making decisions that are to their advantage,
    provide bad advice that will be trusted in light of his position,
    or misrepresent consensus that could be interpreted as mere error.

• Well, the co-chair of this group - literally - works for the NSA.

• We're gonna have a problem here.

It is a crystal-clear, indefensible, classic conflict-of-interest -
Kevin M. Igoe literally works for an attacker we are trying to defend
against!

I mean no disrespect to him as a person: please record that. But I'm
sure that if he is being honest, he will understand the concerns, and
gracefully resign his position.

He might be an ethical fellow, and dislikes how their SIGINT appears
to have fatally undermined their COMSEC. Sadly, I don't KNOW that; and
the trouble is, it raises the highly uncomfortable, but sadly
unavoidable, impression that he could instead be employed to undermine
the work of this group.

In light of what we do know about BULLRUN, it is entirely reasonable
for us to be uncertain, and to doubt, whether Kevin is working in the
best interests of the internet.

And it is reasonable for us to fear that instead, he may be working in
the best interests of his employer - which, sadly, appear in light of
IETF 88 and related discussions, to have been in direct conflict.

He has to go. Nothing personal.

> chairs to be the target of these accusations.

IETF 88 specifically addressed the importance of public oversight and
scrutiny in the evaluation of cryptographic standards.

So, on the contrary, I am extremely glad that the effect of your draft
was a fresh round of public scrutiny and oversight. Thank you for that.

[Just to clarify: One of the co-chairs, Kevin M. Igoe, openly works for
 the NSA and is the source of raised concern here. I have no cause for
 concern about the other co-chair, David McGrew, who works for Cisco.]

> flaws that would cause it to be inappropriate as a TLS cipher

I note that you feel protective, even hotly defensive, of your work.
Others have raised concerns which appear to remain insufficiently
addressed. Beyond that, I won't comment within this discussion.

- -- 
/akr

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Dec 2013 14:49:19 +0000

> I'd like to acknowledge the receipt of your request.

Just to note: the original request and follow-ups have
been sent to [email-masked] and not [email-masked] which
means they didn't get filtered as cfrg mail usually does
for me. I think both aliases for the list work though,
but better to use the proper list address. (As done
here.)

S.

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 21 Dec 2013 09:25:53 -0800

On Sat, Dec 21, 2013 at 2:42 AM, Eggert, Lars <[email-masked]> wrote:
>
> I'd also like to ask CFRG participants to discuss the arguments you are raising

Hi Lars,

I think the issues here are also relevant to the IETF WGs which rely on CFRG.

I hope there's some way to engage this broader set of stakeholders in
the discussion.  I admit I'm not sure the best way to do that.

Trevor

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Dec 2013 17:32:59 +0000

> I think the issues here are also relevant to the IETF WGs which rely on CFRG.

I think that's a misunderstanding. IETF WGs can choose to ask
CFRG something and are then free to figure out what they think
of any answers received, so "rely on" is not correct. And it
doesn't happen often, so we don't have a broad set of IETF WGs
with participants that are familiar with CFRG. Those that are
are probably subscribed here. I'd say Lars is right that CFRG is
probably the best place for discussion.

S.

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 21 Dec 2013 09:53:24 -0800

On Sat, Dec 21, 2013 at 9:32 AM, Stephen Farrell
<[email-masked]> wrote:
> of any answers received, so "rely on" is not correct.

Hi Stephen,

My impression is that WGs such as TLS do indeed rely on CFRG opinion.
Perhaps that's their choice rather than an IETF mandate.  Nonetheless
it does occur, as was quite clear in the handling of Dragonfly:

"The TLS WG isn't chartered to evaluate cryptographic mechanisms, so
where there is some question we generally rely on CFRG for an opinion"
 - Eric Rescorla, TLS WG Chair

http://www.ietf.org/mail-archive/web/tls/current/msg10819.html

Trevor

---

From: Watson Ladd <[email-masked]>
Date: Sat, 21 Dec 2013 09:58:39 -0800

> susceptible to attacks that dragonfly is provably resistant to

There are no proofs for Dragonfly. And this is not about any particular
protocol, but rather Kevin's misrepresentation of list consensus to the TLS WG.

> to this day there is no known attack against it.

The situation is much worse: Dragonfly falls apart in the standard
model for contrived hash functions.
In the ROM nothing was known. Should CFRG decide this is adequate for
a protocol?
I think that CFRG should take a much harder line due to a long and
checkered history of
protocols falling apart because of a lack of proof. The CFRG exists
because the IETF has
made inexcusable cryptography errors.

> no matter what changes are done.

The reasons why the TLS WG doesn't feel like a PAKE is needed are orthogonal
to the issues of Dragonfly's review by the CFRG. Let's try to focus on
the relevant claims.
The CFRG has been reactive and seems to have ignored the IETF 88
revelations that
protocols might be backdoored. Dragonfly did not go through a process
that lead to adequate
discussion.

>   There is no substance to this complaint and I hope it is

I think I can make a last call on time, and see if anyone says no. In
fact, I think a perl script can do it.
Kevin didn't properly represent the state of the CFRG list, nor did he
properly indicate he was going to
relay approval to the TLS WG. This in effect meant that the CFRG was
one person: Kevin.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Dec 2013 18:03:56 +0000

> it does occur, as was quite clear in the handling of Dragonfly:

Yes, dragonfly was handled that way. I can't recall when was
the time before that to be honest, so its rare. My main point
was that you shouldn't expect a large well-informed population
of IETF participants when it comes to this discussion. Those
that are well-informed, are probably here already.

S.

---

From: Tao Effect <[email-masked]>
Date: Sat, 21 Dec 2013 14:00:03 -0500

IMO, there are two separate issues here:

(1) This "Dragonfly" protocol, and whether it's a good one. This is an issue that should be discussed on purely technical merits.

(2) Whether or not Kevin Igoe should be removed as CFRG co-chair because of his acknowledged employment with the NSA.

On (1) I have no comments, as I have no idea what "Dragonfly" is.

On (2), I think it's a no-brainer what the correct course of action here is in terms of the "right thing to do", ethically speaking.

The NSA has lost every ounce of credibility that it ever had as an ethical actor. They have now firmly established themselves as one of the most ethically bankrupt organizations on planet Earth.

Their own internal documents show that it is part of their mission to sabotage the work of standards bodies. This along is enough to kick every one of their members out of all such organizations.

So here's another vote in favor of Trevor's proposal.

Cheers,

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

---

From: Tao Effect <[email-masked]>
Date: Sat, 21 Dec 2013 14:01:19 -0500

Cheers,

- Greg

---

From: Tao Effect <[email-masked]>
Date: Sat, 21 Dec 2013 14:23:53 -0500

One more reason in favor of the proposal:

The NSA's reputation is contagious.

Any organization with any traceable links to the NSA will undermine its own credibility, including the CFRG.

Cheers,
Greg

P.S. There was a typo in my previous email: "along" should be "alone".

---

From: Tao Effect <[email-masked]>
Date: Sat, 21 Dec 2013 14:58:46 -0500

Thanks for mentioning that Ran!

That section reads like something I'd agree with normally.

However, I think it must be scrutinized closely in light of the known facts. It may very well be misguided advice (like patents turned out to be, at least in the case of software).

> This has been a guiding principle for the IETF, that kept it clean and free of corporate and other non-technical pressures.

The facts:

1. Actor "NSA" is on the record as wanting to send representatives to sabotage standards bodies.

2. Kevin Igoe works for the NSA and has been appointed as co-chair of a group that recommends standards.

3. Kevin's financial interests depend on the NSA's approval of the work that he's doing.

Ran, please explain: how does ignoring these facts keeping the IETF "clean and free of corporate and other non-technical pressures"?

- Greg

On Dec 21, 2013, at 2:48 PM, Ran Canetti <[email-masked]> wrote:

> 
> From the IETF page for newcomers:
> 
> " If you work for a company and the IETF will be part of your job, you must obviously clear this with your manager. However, the IETF will always view you as an individual, and never as a company representative."
> 
> This has been a guiding principle for the IETF, that kept it clean and free of corporate and other non-technical pressures. Departing from this principle is a slippery slope. Let's not.
> 
> Ran
> 
> 
> 
> On 12/21/2013 2:23 PM, Tao Effect wrote:

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 21 Dec 2013 16:29:13 -0500

> I'd like to request the removal of Kevin Igoe from CFRG co-chair.

Regardless of the conclusions that anyone comes to about Dragonfly
itself, I agree with Trevor that Kevin M. Igoe, as an employee of the
NSA, should not remain in the role of CFRG co-chair.

While the NSA clearly has a wealth of cryptographic knowledge and
experience that would be useful for the CFRG, the NSA is apparently
engaged in a series of attempts to weaken cryptographic standards and
tools in ways that would facilitate pervasive surveillance of
communication on the Internet.

The IETF's public position in favor of privacy and security rightly
identifies pervasive surveillance on the Internet as a serious problem:

https://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html

The documents Trevor points to (and others from similar stories)
indicate that the NSA is an organization at odds with the goals of the IETF.

While I want the IETF to continue welcoming technical insight and
discussion from everyone, I do not think it is appropriate for anyone
from the NSA to be in a position of coordination or leadership.

----

Kevin, the responsible action for anyone in your position is to
acknowledge the conflict of interest, and step down promptly from the
position of Co-Chair of the CFRG.

If you happen to also subscribe to the broad consensus described in the
IETF's recent announcement -- that is, if you care about privacy and
security on the Internet -- then you should also reveal any NSA activity
you know about that attempts to subvert or weaken the cryptographic
underpinnings of IETF protocols.

Regards,

	--dkg

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 22 Dec 2013 09:14:52 +0000

Hi,

> the discussion.  I admit I'm not sure the best way to do that.

the best way is on this list. You're email was about concerns with a chair of the CFRG, and the CFRG list is hence the best place for the discussion.

Your initial email was CC'ed more widely, as was my replay directing people to discuss on [email-masked], so everyone interested should be aware of where to send email.

Lars

---

From: David McGrew <[email-masked]>
Date: Tue, 24 Dec 2013 00:14:08 -0500

On 12/20/2013 11:01 AM, Trevor Perrin wrote:
> 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

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?

> 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

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.

> criticism of Dragonfly, the TLS WG ceased work on a Dragonfly

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

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

> 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

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

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 24 Dec 2013 04:02:43 -0800

Hi David,

(trimming recipients back to CFRG list)

On Mon, Dec 23, 2013 at 9:14 PM, David McGrew <[email-masked]> wrote:
> 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?

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

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

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

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

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

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

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

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

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

> 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

---

From: David McGrew <[email-masked]>
Date: Tue, 24 Dec 2013 12:57:39 -0500

Hi Trevor,

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

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

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

> 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

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?

> angst will attend any decision we make.  That's life in crypto.

Agreed on the uncertainty.

>> but these are important questions to consider.

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.

> conduct of Research Group business" [1].

That's a fair point.

>   For the CFRG chairs this has

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.

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

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

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

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

> 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

---

From: Brian Weis <[email-masked]>
Date: Tue, 24 Dec 2013 10:45:25 -0800

On Dec 24, 2013, at 4:02 AM, Trevor Perrin <[email-masked]> wrote:

[snip]

> candidates.  Is that right?

I'm appalled that now this discussion has apparently been reduced to
a thinly veiled hint at conspiracy and/or collusion. Sheesh. Get to 
know IRTF process, please.

Brian

---

From: Tom Ritter <[email-masked]>
Date: Tue, 24 Dec 2013 14:16:18 -0500

> know IRTF process, please.

I did not interpret it as a reference to conspiracy, rather a note of the
lack of opportunity to raise objections, ask for volunteers, or
nominations. I'm not familiar with the actual appointment in question, it's
likely Kevin was an active participant that, aside from his employer, made
sense. But, if there was no opportunity to raise concern/conflict of
interest, this lack of opportunity to provide input is worth noting. Not
that it means conspiracy, just that it makes this conversation all the more
relevant (as there is no 'you could have replied to this thread' argument).

-tom

---

From: Brian Weis <[email-masked]>
Date: Tue, 24 Dec 2013 11:53:09 -0800

On Dec 24, 2013, at 11:16 AM, Tom Ritter <[email-masked]> wrote:

> I did not interpret it as a reference to conspiracy, rather a note of the lack of opportunity to raise objections, ask for volunteers, or nominations. I'm not familiar with the actual appointment in question, it's likely Kevin was an active participant that, aside from his employer, made sense. But, if there was no opportunity to raise concern/conflict of interest, this lack of opportunity to provide input is worth noting. Not that it means conspiracy, just that it makes this conversation all the more relevant (as there is no 'you could have replied to this thread' argument).
> 
> -tom
> 

As has been stated, IRTF work is done by individuals and are volunteers. A certain level of trust is required in those volunteers required in order to have an effective organization. The relevant trust here is that the CFRG co-chair, the IRTF Chair and the IAB at the time the decision was made made a well informed decision. If I recall correctly, the CFRG was not very active at that time and the leadership made the best decision they could. It is not useful to go back and question their decision making process unless you are questioning the honesty and competency  of the responsible people of the time. This is what I find objectionable. That's just more witch hunting.

There has always been on opportunity to raise objections to the decision made, and indeed now it has happened. The appropriate process is being followed but only if it stays focused.

Brian

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 24 Dec 2013 12:09:42 -0800 (PST)

> relevant (as there is no 'you could have replied to this thread'

  The lack of opportunity to raise objections is due to the fact that he
(and the others who recently subscribed to CFRG because they follow him
on twitter and heeded his call to join the crusade) were not involved at
the time. These complaints ring particularly hollow.

  Realize too that had Kevin's employer not given these people the
opportunity to strike their fashionable pose there would be no discussion
of IRTF process or what the CFRG's place in the world is. So this really
isn't about IRTF process or the CFRG. It all comes back to the conspiracy
theory, and the guilt-by-association, and the fallacious ad hominem
attacks.

  Dan.

---

From: Tao Effect <[email-masked]>
Date: Tue, 24 Dec 2013 15:25:32 -0500

On Dec 24, 2013, at 3:09 PM, Dan Harkins <[email-masked]> wrote:

> the time.

Sorry, I don't quite follow your logic.

Are you saying that the appointment was made without a request for
feedback because some people were not subscribed to this list?

> of IRTF process or what the CFRG's place in the world is.

The issues that have been raised are nothing but "fashionable poses"?

How do you figure that?

> So this really

What is the "conspiracy theory"?

What are the "fallacious ad hominem attacks"?

Thanks,
Greg

---

From: Henrick Hellström <[email-masked]>
Date: Tue, 24 Dec 2013 21:34:05 +0100

> theory, and the guilt-by-association, and the fallacious ad hominem

Sorry, you lost me. Are you implying that everyone here except me is a 
US citizen, and that the purpose of this group is to promote the 
national interest of the USA?

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 24 Dec 2013 13:47:59 -0800 (PST)

> national interest of the USA?

  No, absolutely not. I'm not implying anything of the sort. I'm not
quite sure how you came to that impression.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Dec 2013 21:51:17 +0000

> quite sure how you came to that impression.

But you are implying that we are all alive and free to discuss our opinions because the NSA is watching our backs and presumably foiling the murderous plans of the terrorists?

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 24 Dec 2013 14:13:07 -0800 (PST)

> feedback because some people were not subscribed to this list?

  No, that would be ludicrous.  I'm saying that the complaints today of
people who were not involved in the CFRG at that time and who still
do not understand the process involved ring particularly hollow.

> The issues that have been raised are nothing but "fashionable poses"?

  Because the complaints in this thread about the NSA are not doing
anything to address the issue of pervasive monitoring. In fact, as
Stephen pointed out, you're detracting from that important effort with
this stupid crusade and your (excellent quote) "infantile gibberish".

  What you're doing is striking a pose, and giving yourself the opportunity
to pat yourself on the back for your stand against the NSA. You're not
actually helping out here though.

> What are the "fallacious ad hominem attacks"?

  Read the thread. And read the Tao of the IETF. And learn about how
things work here. Test the waters before you dive in, that way you
don't bang your head on a rock and hurt yourself.

  Merry Christmas to all!

  Dan.

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 24 Dec 2013 23:02:58 +0000

On 24 Dec 2013 20:09, Dan Harkins wrote:

> [...recently subscribed... twitter... crusade... hollow...]

Dan? I'm not sure defensiveness helps the discussion. (I can't
speak for anyone else, but I don't think I've ever really used
Twitter.) It's nearly Christmas. Relax.

I doubt the discussion will make much substantive progress either way
until, at least, we hear what Kevin has to say.

Given the timing, however, he may well be on holiday.

> opportunity [...] there would be no discussion of [...] what the 
> CFRG's place in the world is.

And perhaps we can use that as a positive opportunity.

Many WGs, including TLS, have a hell of a lot of work ahead of them in
light of perpass. Many will need trustworthy help with crypto, because
we are going to need a lot more robust crypto to start making this
threat model's lives more difficult than they are at present.

We have a bunch of new primitives we could use to replace the
now-less-certain ones as we move forward: some of these could be
extraordinarily useful for TLS1.3 - like, yes, (Curve|Ed)25519 -
Safecurves is exactly (the beginning of) the kind of work we need, I
think.

And CFRG could, and should, help with that: recommendation of
best-practice primitives, review of designs, protocols and structures
- - I'm not sure if review of core implementations falls within its
remit of where practice and theory meet, but _someone_ definitely
ought to do much more review of where the crypto actually touches the
ground (of all the areas, that is the one NSA targets most
successfully, according to Snowden).

I do think the perception of the trustworthiness of CFRG's advice, and
thus how useful the WGs are likely to find it, will be very strongly
coloured by this discussion, and whatever the ultimate outcome is;
hence the (extraordinary) necessity of it being raised.

Of course, that doesn't mean we necessarily have to wait. I note the
drafts David mentions; I'll take a look at them, and I'll reply to
Watson's thread when I have, but they seem like a start, at least.

Season's greetings, everyone.

- -- 
/akr

---

From: Tao Effect <[email-masked]>
Date: Tue, 24 Dec 2013 19:04:43 -0500

> do not understand the process involved ring particularly hollow.

OK, then explain why no opportunity was given to raise objections (at that time).

Is that just how the CFRG operates? The chair (or co-chair) picks the person they want to co-chair and the rest of the community has no say in it?

This reply of yours doesn't answer that question.

> actually helping out here though.

OK, so do I understand your position correctly, that the complaints about the
conflict of interest with the NSA co-chairing an organization whose work it
wants to sabotage are without any merit?

You're saying that that issue is irrelevant, do I understand you correctly?

>  Read the thread.

Yes, I did. Did you?

I don't see any conspiracy theories or "fallacious ad hominem attacks".

Point them out or stop inventing things, please.

> And read the Tao of the IETF.

I did (a while ago).

>  Merry Christmas to all!

Yes, Happy Holidays to all!

Cheers,
Greg

---

From: Tao Effect <[email-masked]>
Date: Wed, 25 Dec 2013 00:17:49 -0500

Correction, this comment of mine is incorrect:

> Is that just how the CFRG operates? The chair (or co-chair) picks the person they want to co-chair and the rest of the community has no say in it?

It was pointed out to me off-list that David did in fact give the group an opportunity to voice their support or concerns for Kevin's nomination as co-chair:

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

Sincere apologies for my mistaken understanding about that.

I think I must have either misread or repeated a mistaken understanding from one of the emails I'd read in this thread.

Cheers,
Greg

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Dec 2013 07:19:20 +0000

> It was pointed out to me off-list that David did in fact give the group an opportunity to voice their support or concerns for Kevin's nomination as co-chair:

It should also be noted that although David did so in this case, the chair job at the IETF and IRTF is seen as administrative. Technical understanding of the issues is required, but the chair is neither expected to be the foremost expert in the group not expected to choose the path that a group will follow. Because of this, chairs are mostly appointed by the ADs or the IRTF chair without consulting the group. When stating that "this algorithm is OK in this aspect, but has a timing issue", their words should carry no more weight than any other participant, and often less weight than some contributors who are experts in their fields.  CFRG right now has two chairs who are experts, but that is not an absolute requirement for a successful group.

Yoav

---

From: David McGrew <[email-masked]>
Date: Thu, 26 Dec 2013 12:42:07 -0500

Hi Greg,

Ive trimmed the email to just the point that I can address best:

On 12/24/2013 07:04 PM, Tao Effect wrote:
>>   I'm saying that the complaints today of

I described the process by which CFRG has come by the particular 
co-chairs in a recent email to Trevor.   Let me repeat that to make sure 
that your questions get answered, and provide a bit more detail.

    for approval.  If approved, the charter is placed on the IRTF Web 
site, and

When Ran stepped down, I sought a co-chair.   Strictly speaking, there 
does not need to be a co-chair.   It is sufficient for IRTF purposes to 
have a single chair.   In practice, it is better to have two chairs.   
This is especially true when the RG chair also authors RG documents; 
having a second chair enables us to avoid having a potential conflict of 
interest.   There was not a public call for a co-chair to replace Ran; 
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, 
who were people that were active in CFRG and in IETF security area at 
that time.  Lars Eggert, who chairs the entire IRTF, was also involved 
in these discussions and was quite helpful.   I asked the RG to affirm 
Kevin in the role of co-chair.  I cannot recall anyone expressing any 
reservations about Kevin at the time, either publicly or privately.

The Research Group needs to have chairs that it trusts, and who are 
trusted by the broader IETF and Internet communities that they work 
with.  People who have worked with Kevin trust him, but there is 
widespread mistrust of NSA in those broader communities.   The IRTF 
policies have not anticipated this situation.   Please bear with the 
IRTF leadership team for a little bit; the holiday week in the U.S. has 
slowed us down.

David

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 27 Dec 2013 15:21:53 +0000

(Restoring the subject line, so Lars can better follow the thread.)

On 26 Dec 2013 20:07, Igoe, Kevin M. wrote:
> While NSA’s SIGINT mission gets all the press (especially now), the
> Agency has another mission: Information Assurance.

Unfortunately, given the SIGINT Enabling Project has used the NSA's
Information Assurance mission as official cover for sabotage of
cryptographic primitives¹, implementations², and standards³, not to
mention their interesting conduct in statements and enquiries so far,
any trust or confidence once placed in the NSA for anything by anyone
has now been fatally, critically, permanently undermined.

I can't imagine the NSA's IA department is pleased about that at all
(particularly if it wished to, in time, use the protocols and COTS
software and hardware, such as your BlackBerry, that its SIGINT
department meanwhile was no doubt busily trying to subvert). That is,
of course, an internal issue between your respective departments,
NIST, the wider US Government, and of course the American people it
serves.

No comment is required: I understand you may find yourself in a
difficult position regarding such things. However, if you (or anyone
with the knowledge) felt yourself ethically able and willing to
disclose the specific nature and existence of any vulnerabilities so
seeded - and indicate if, and how, you have addressed them in any
software or hardware you have fielded - I would heartily encourage it.

We certainly aren't pleased about it, because to meet the 'perpass'
threat posed by Nation State Adversaries (a convenient initialism)
discussed at IETF 88, we're going to have to change, redesign and
deploy several new and improved primitives, protocols, standards and
implementations. This will be hard, and yes, will take years to
finish; the IETF, and CFRG, will play a vital part, I feel.

As the other co-chair, David McGrew correctly points out:
> with.

Our work needs to be carried out openly and transparently so that it
can be trusted. And that process needs to be administered by people we
mistrust as little as possible, and clearly not by an
openly-acknowledged agent of an organisation systematically trying to
sabotage the process of devising and deploying strong cryptography:
it is a simple, and unavoidable, conflict of interest, I'm afraid.

I therefore reiterate the call for your resignation as co-chair.
I mean no personal disrespect, but it's clear you understand the
situation.

I hear Mr Schneier might be too busy. Besides, the job is, as you say,
unglamorous, and administrative. Still, perhaps a trusted
international cryptographer (perhaps in a jurisdiction with no
National Security Letters or similar means of potential coercion to
overlook a potential backdoor?), with the time available would be a
good choice?

I'm not sure a similar situation has arisen before, and therefore
there might well be no established procedure; of course, we can be
patient. Perhaps, if your colleagues and counterparts could be
persuaded to curtail their excesses, a similar situation may not arise
again. I remain guardedly hopeful.

In any case, I wish yourself (and your daughter) well, and please have
a enjoyable holiday.

___
1. Specific documented example: Dual_EC_DRBG - a backdoor that couldn't
   have been more obvious if you'd erected a flashing neon sign and
   driven a mounted parade with a marching band through it. We have no
   reason to expect other 'enablings' to be as obvious, of course.
2. Specific documented example: RSA Security; BSafe; $10m; Dual_EC_DRBG.
3. 802.11; GSM; LTE. Bluetooth? (Even perhaps TLS?) Hard to be sure...
   it's the kind of subtle sabotage that makes the result awful by
   design, rather than simply awful by committee; the two are hard to
   distinguish, which is the point, and the end result is similar,
   as is the need to improve and fix.

- -- 
/akr

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 27 Dec 2013 07:56:43 -0800

On Tue, Dec 24, 2013 at 9:57 AM, David McGrew <[email-masked]> wrote:
[...]
> 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.

Which discussion?  The only substantial discussion of Dragonfly at a
CFRG meeting appears to be at IETF 83.  Is that what you're referring
to?

http://www.ietf.org/proceedings/83/minutes/minutes-83-cfrg.txt

> community, it is often regarded as oversold.

As a member of the "crypto practice community" I disagree.  Key
agreement protocols are widely understood to be a tricky area where
formal analysis is crucial.  Dragonfly's lack of such analysis was a
red flag.  Jonathan Katz, a world-class cryptographer, raised the
issue repeatedly.  The CFRG chairs ignored him and endorsed Dan
Harkins' bluster.

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

Seems like CFRG could use more outreach to the cryptography community
and less to the intelligence community.

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

I see.  That's terrifying.

> than affirmation by the RG?

If the IETF/IRTF community endorses Kevin through an open process I'd
give up participating in IETF/IRTF any further.  That's not
"acceptance", but you wouldn't have to listen to me any more.

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

I'm not advocating a formal policy.  I believe the selection (or
removal) of chairs involves weighing many factors, and is best handled
on a case-by-case basis.

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

I think those are bad ideas which would not prevent sabotage and would
burden innocent contributors.

> What do you mean by this?   Are you saying that the CFRG chairs mishandled
> the Lucky-13 disclosure?

No.  From what I can tell Kenny Paterson handled it well.

But amongst those defending Kevin, a major theme seems to be that
trustworthiness and expertise is not important for IETF/IRTF chairs
since they're presiding over an open process.

I disagree since chairs wield a great deal of power in the IETF/IRTF
process.  The "Lucky 13" disclosure highlights an additional duty
which has been entrusted to CFRG chairs and which is hard to audit.

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

That's a good description.  But so is your phrase "steering the RG in
an unfruitful direction".  Kevin's paragraph is below:

"""
Scott Fluhrer proposed an elegant change to DragonFly that fixes this.
 In the EC case, replace
the while-loop with a for-loop, say “for t = 1,,,,40”.  On each pass
through this for-loop generate
a possible x- coorodinate as in DragonFly,  saving off the first x
value which corresponds to a
point on the curve.  The only thing that can go wrong here is doing
all 40-iterations without
finding a good x-coordinate.  This is quite unlikely to occur (~
10^-12), but when it does occur
it gives 40 bits of information about the password.  In some VERY high
volume applications it
might be prudent to choose a value larger than 40.
"""

>>> branches
> could get the impression that the proposed mitigation to timing attacks is
> "hard to implement" rather than "ineffective", in your opinion.

I'm still not sure what you're asking.  Let's just look at a crude
analysis of the "40-loops" countermeasure Kevin endorsed, comparing
CFRG draft-00 vs draft-01/draft-02.

Let's assume that modular square roots are calculated via modular
exponentiation, and that Legendre symbol calculations take less time.
Let's also ignore the variable time taken by a Legendre symbol
calculation and other conditional logic, and just count the number of
ops.

In draft-00, the hunt-and-peck loop in 3.2.1 performs Legendre symbol
calculations until it finds a square (probability ~1/2), at which
point a square root is performed.  So:
 - 1 modular exponentiation
 - Variable number of Legendre symbol calculations
   - geometric distribution with mean ~2, variance ~2

In draft-01 and draft-02, the hunt-and-peck loop continues until it
completes 40 loops, with a probability ~1/2 of performing a modular
exponentiation on each iteration.  So:
 - Variable number of modular exponentiations
   - binomial distribution with mean ~20, variance ~10
 - 40 Legendre symbol calculations

The 40-loops algorithm was intended to reduce timing variance but
instead increases it, and increases computation cost as well.  So I
think "ineffective" is a fair description.  Do you agree?

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

Sure.  Crypto's hard.  Mistakes happen.  But I'm uncomfortable with
the volume of mistakes in Kevin's handling of Dragonfly:
 * Endorsing Dragonfly despite better alternatives in the literature
 * Twice suggesting a way of deriving the DH generator which makes the
protocol breakable
 * Endorsing an ineffective timing-attack countermeasure
 * Misrepresenting CFRG consensus to TLS WG

Trevor

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 27 Dec 2013 18:17:52 +0100

>  * Misrepresenting CFRG consensus to TLS WG

I think the issue here is more of procedure rather than individuals or
affiliations. Even if Mr. Igoe is no longer the co-chair the same
process could allow for intentional or unintentional mistakes. I believe
it is more important to improve the process of IRTF expressing its
opinion to IETF working groups rather than blame individuals or
organizations. For example, if the process would include a summary of
the discussion and the opinions of people involved it would be hard for
anyone communicating to misinterpret consensus or opinions.

I am also more comfortable as an outsider to have participants with
their NSA (or any other agency's) affiliation in the clear.

regards,
Nikos

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Dec 2013 10:32:14 -0800 (PST)

(trimming the cc list. Trevor, you should really read what people
write and honor their requests)

On Fri, December 27, 2013 7:56 am, Trevor Perrin wrote:
>> if

  Yes, that would've been a good meeting to discuss it at. Or you
could've brought anything up on the list over the past couple of
years.

  As far as the _other_ discussion is concerned, the one that prompted
your starting of this thread. It has been shown that the process you
and your twitter followers are complaining about was open and
transparent, contra your mischaracterizations of it.

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

  And as a member of the "crypto practice community" I agree with David.
The issue that Jonathan Katz raised concerned the inability to prove the
protocol secure in the random oracle model. The reason is that in that
model the adversary has certain capabilities, like reveal(). The problem is
this:

  1. assume there is no key confirmation step in the protocol
  2. adversary as man-in-the-middle adds 1 to Bob's scalar
  3. adversary issues reveal() query to both Alice and Bob to
      obtain secrets
  4. adversary does off-line dictionary attack.

Now, this is indeed a problem with proving the protocol secure in the
random oracle model but it is not attack against dragonfly (or TLS-pwd).
That is because if an adversary has that much control over BOTH sides
of a TLS connection then all bets are off and the ability to do an off-line
dictionary attack after launching a man-in-the-middle attack against
entities it controls is the least of your worries. In addition, there is key
confirmation in the protocol and it does foil this attack. So in the "crypto
practice community" this is not viewed as an attack.

  The other issues Dr. Katz raised were:

  1. don't use the session key as a key confirmation key. A good
      suggestion but I didn't.
  2. validate the received elements. Good suggestion, which resulted
      in a change to the draft.

  So there is no "bluster". There was not a repeated raising of any
issues. There's just a continued (intentional?) misunderstanding by you
of what happened, what was said, and what it meant.

> and less to the intelligence community.

  And it could do with less of another community too….

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Dec 2013 12:02:39 -0800 (PST)

On Tue, December 24, 2013 1:51 pm, Yoav Nir wrote:
> But you are implying that we are all alive and free to discuss our
> opinions because the NSA is watching our backs and presumably foiling the
> murderous plans of the terrorists?

  Absolutely not! Again, I'm not sure how you got the impression I was
saying anything like that. I'm not sure what is causing those knees to
jerk so reflexively.

  In fact, I don't believe any murderous plans by terrorists have been
foiled by the the NSA's pervasive monitoring. And given that the NSA has
obviously not learned important lessons from the Kevin Mitnick affair
I'm not sure they are capable of safeguarding that data even if it was of
use in protecting us against murderous terrorists.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Dec 2013 15:12:33 -0800 (PST)

Yoav, Henrick (and probably others),

  It has been pointed out to me in private email that this sentence is

>>>>> of IRTF process or what the CFRG's place in the world is.

  I meant that Kevin's employer presented a convenient (and fashionably
popular) target to criticize. I did not mean that his employer was doing
anything to create the environment in which people can comfortably (or
fashionably) criticize.

  Hope this clears it up.

  regards,

  Dan.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 27 Dec 2013 18:56:57 -0500

> anything to create the environment in which people can comfortably (or

This whole mess started when thanks to your draft, it was revealed
that a lack of effort by the CFRG
was reported as a positive statement on security. The supposedly
"open" CFRG had over the years atrophied,
to the point where the chair would think that no objection was
equivalent to a positive review. As a participant,
do you feel that that is an adequate foundation for this WG's activities?

That the chair works for an organization devoted to subverting crypto
standards, and that had in fact done so on several
occasions (DUAL_EC_DRNG, Crypto AG, the RSA side payment attack) makes
this sort of misstatement, and the fact
that several long-time members regard it as acceptable, quite
worrying. The NSA is a *fashionable* target because it's
one of the few actors with a mission involving subverting standards:
if Cisco makes a secure standard they prefer, I really
don't care.

Do you believe the CFRG has provided good service to the IETF during
the years it has been active? Do you believe
that the CFRG has increased the security of IETF produced protocols?
Let's focus on the issues here: the CFRG
isn't doing its job.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Dec 2013 17:44:40 -0800 (PST)

On Fri, December 27, 2013 3:56 pm, Watson Ladd wrote:
> equivalent to a positive review.

  You continue to misrepresent what happened. TLS did not ask for
approval or blessing, or a "positive statement" on dragonfly. "Is there
a problem with this?" is not the same as "do you think this is the bee's
knees?" Certainly you must understand that so your continued
misrepresentation can only be intentional.

>                                                     As a participant,

  Being a non-participant, you have formed a conclusion about what
happened vis-a-vis dragonfly and the CFRG and then gone back in
time to justify that conclusion. That is illegitimate.

> if Cisco makes a secure standard they prefer, I really

  I'm glad you acknowledge the fashionableness of the NSA target.
The problem is that people are misconstruing "making a statement"
with action. They think that a provocative (and exaggerated) public
statement is somehow bold and edgy and that is enough to elevate
the speaker to a certain status (pat oneself on the back). There is a
sad disconnect today between rhetoric and action, people seem to
be more happy tweeting hyperbole to slavish followers than actually
helping solve a problem. And I count you among them.

  The IETF is making a very serious effort to address the problem of
pervasive monitoring and it has asked for help. You have trivialized
that effort with your grandstanding. What you do is for your own
aggrandizement, not for the betterment of the Internet community
as a whole.

> Let's focus on the issues here: the CFRG

  I actually believe it is answering the questions it was asked in an
appropriate manner. It is doing it's job.

  You have told me previously that you think it only takes 30 minutes
to generate a standard, as opposed to the 2+ years I said it takes
(and I have one of your unimplementable, laughable, and incredibly
ambiguous "30 minute standards" too). That, to me, illustrates, at one
end, a cute and quaint naivety, and on the other, an arrogant and
clueless disregard for the work of others.

  It might help if you actually get involved in the process and help
solve problems before you tell people that the process they went
through is wrong. You have stated numerous times about the
inadequacy of RC4 in TLS. So, write an Internet-Draft on the subject!
Accept and resolve comments. Get involved before you pontificate
about how people are doing things wrong.

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 28 Dec 2013 09:04:54 +0000

> anything to create the environment in which people can comfortably (or

It does. Thanks

Yoav

---

From: Tao Effect <[email-masked]>
Date: Sat, 28 Dec 2013 13:36:47 -0500

Based on Kevin's reply, dated Dec. 26th, it's clear that he has no interest in stepping down as co-chair.

Is there a process in place that would allow the community of the CFRG to vote on the matter?

If not, here's a simple one that allows for semi-secret vote (votes are revealed to only a tiny fraction of the members):

1. Select two or three people who participated in this discussion thread and expressed opposing views, call them the "Ballot Team"
2. Allow those who have participated in this discussion thread (or related threads, but you've gotta be specific) to send their vote to the Ballot Team via email.
3. Have the Ballot Team check to make sure the email is from someone who participated in this discussion, and send a confirmation reply back to them.
4. Upon receiving a confirmation back with the previous email quoted, mark down their vote.
5. Set a deadline for votes.
6. Have the Ballot Team publicly announce the number of "Yay" and "Nay" votes. If they match up, we can reasonably expect that no cheating happened.

Just an idea, probably not bullet proof, but it considers some of the potential issues of doing such a vote.

A better system, of course, would involve us knowing the result and nobody knowing how anyone else voted.

Cheers,
Greg

On Dec 27, 2013, at 10:21 AM, Alyssa Rowan <[email-masked]> wrote:

> Signed PGP part
[snip]

---

From: Robert Ransom <[email-masked]>
Date: Sat, 28 Dec 2013 10:39:00 -0800

> Is there a process in place that would allow the community of the CFRG to

IETF does not vote.

Robert Ransom

---

From: Tao Effect <[email-masked]>
Date: Sat, 28 Dec 2013 13:51:58 -0500

> IETF does not vote.

Oh, that's right, I think I remember now that to reach consensus it needs there to be "no objections" within some sort "reasonableness"?

If that's the case then please just ignore that email.

Cheers,
Greg

---

From: Yoav Nir <[email-masked]>
Date: Sat, 28 Dec 2013 19:06:10 +0000

>> Is there a process in place that would allow the community of the CFRG to

What Robert said.

We did not appoint Kevin, so we don't have firing power either. Officially, it was the chair of IRTF who appointed Kevin, so he's the one who can remove him.

On December 21st (that's just a week ago) Lars acknowledged ([1]) Trevor's request.

The rest of the process should be described in RFC 2014 ([2]), but that's missing a lot of stuff. So the rest is my guess of what the process will be like. 

After a few weeks (at least a week after New Year's), when he's satisfied that all the arguments have been made, Lars will consult with David, Kevin, and whoever else he thinks is appropriate, and decide what to do with the petition. 

If Trevor or you or anyone else is not satisfied with Lars's decision, there's likely some avenue of appeal. My guess is first to the IRSG, and if you're still not satisfied, to the IAB.

Yoav

[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03558.html
[2] http://tools.ietf.org/html/rfc2014

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Dec 2013 12:48:25 -0800

> Oh, that's right, I think I remember now that to reach consensus it needs there to be "no objections" within some sort "reasonableness"?

No, that's not it either. The IRTF (this is not the IETF) uses a consensus process that is based on loose agreement among reasonable people.

> If that's the case then please just ignore that email.

Done.

--Paul Hoffman

---

From: Tao Effect <[email-masked]>
Date: Sat, 28 Dec 2013 16:36:58 -0500

> We did not appoint Kevin, so we don't have firing power either. Officially, it was the chair of IRTF who appointed Kevin, so he's the one who can remove him.

Thanks very much Yoav!

That helps clear things up a bit for me, although not completely...

I'm trying to combine what you've said here with David's email.

For reference, here's the relevant bit from that email:

On Dec 26, 2013, at 12:42 PM, David McGrew <[email-masked]> wrote:
> When Ran stepped down, I sought a co-chair.   Strictly speaking, there does not need to be a co-chair.   It is sufficient for IRTF purposes to have a single chair.   In practice, it is better to have two chairs.   This is especially true when the RG chair also authors RG documents; having a second chair enables us to avoid having a potential conflict of interest.   There was not a public call for a co-chair to replace Ran; 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, who were people that were active in CFRG and in IETF security area at that time.  Lars Eggert, who chairs the entire IRTF, was also involved in these discussions and was quite helpful.   I asked the RG to affirm Kevin in the role of co-chair.  I cannot recall anyone expressing any reservations about Kevin at the time, either publicly or privately.

So, by combining your statements together, it sounds to me like David did not need the permission of the group to appoint Kevin, but he was polite and decided to ask for it anyway.

Now, however, the group has had a chance to get to know Kevin, whereas before they appeared completely unfamiliar.

Given this extra knowledge, it seems like the group's feedback on the appointment is more informed *now* than it was then, and hence perhaps deserving for more weight and consideration.

David McGrew <[email-masked]> wrote:
> The Research Group needs to have chairs that it trusts, and who are trusted by the broader IETF and Internet communities that they work with.  People who have worked with Kevin trust him, but there is widespread mistrust of NSA in those broader communities.   The IRTF policies have not anticipated this situation.   Please bear with the IRTF leadership team for a little bit; the holiday week in the U.S. has slowed us down.
Yoav Nir <[email-masked]> wrote:
> So the rest is my guess of what the process will be like. 

Roger. Thank you for your help, and all the clarifications and transparency on this!

Cheers,
Greg

---

From: idontneedcoffee <[email-masked]>
Date: Sun, 29 Dec 2013 02:41:16 +0100

I think Kevin _should_ stay as a co-chair. Thanks to the recent "leaks"
of his employer,
he brings a lot of (needed*) attention to CFRG/IETF; if he would resign,
most critics
would consider(most of) their work done, it would lower the level of
mistrust against
cfrg from the general itsec crowd and that would in end-effect leave all
the processes
outlined in this thread as ineffective/questionable in tact. It wouldn't
solve a single issue
of the proponents of this notion(please think it through..) and
undermine the only
measure that can be effective(in limited circumstances) - public
audit/control

in short > If Kevin stays, every step of CFRG will be thoroughly watched
by hundreds
of motivated people - I would not want to give them an easy way to vent
their
frustration when there is some real work(..) that can be fuelled by it..

/idnc

---

From: Alyssa Rowan <[email-masked]>
Date: Sun, 29 Dec 2013 02:34:21 +0000

On 29/12/2013 01:41, idontneedcoffee wrote:

> if he would resign, most critics would consider(most of) their work
> done,

I believe I've thought this through in detail.

If you want to provide more oversight, and more input, and I heartily
encourage that, then please do so. I strongly believe more eyes would
help. But I don't believe that having Kevin remain as co-chair would
help: certainly not.

Rather, in the event no action were taken and he did not resign or be
removed, I believe the wider security community would simply consider
CFRG unfit for purpose, and would not be willing to engage. (More than
one individual has outright said this.)

I do not think that outcome would assist anyone, and it would prevent
us being able to use this RG as a base for providing review of
primitives, protocols and implementations, which needs to be done as
an important step in the long road to address the perpass threat.

- -- 
/akr

---

From: Yoav Nir <[email-masked]>
Date: Sun, 29 Dec 2013 08:42:34 +0000

Wouldn't endorsing ROT13 as the alternate cipher achieve the same goal?

From: Cfrg [mailto:[email-masked]] On Behalf Of idontneedcoffee
Sent: Sunday, December 29, 2013 3:41 AM
To: [email-masked]
Subject: Re: [Cfrg] Requesting removal of CFRG co-chair

I think Kevin should stay as a co-chair. Thanks to the recent "leaks" of his employer,
he brings a lot of (needed*) attention to CFRG/IETF; if he would resign, most critics
would consider(most of) their work done, it would lower the level of mistrust against
cfrg from the general itsec crowd and that would in end-effect leave all the processes
outlined in this thread as ineffective/questionable in tact. It wouldn't solve a single issue
of the proponents of this notion(please think it through..) and undermine the only
measure that can be effective(in limited circumstances) - public audit/control

in short > If Kevin stays, every step of CFRG will be thoroughly watched by hundreds
of motivated people - I would not want to give them an easy way to vent their
frustration when there is some real work(..) that can be fuelled by it..

/idnc

On Dec 28, 2013, at 10:51 AM, Tao Effect <[email-masked]><mailto:[email-masked]> wrote:

Done.

--Paul Hoffman

Cfrg mailing list

[email-masked]<mailto:[email-masked]>

Email secured by Check Point

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 29 Dec 2013 09:09:09 +0000

Hi,

> Is there a process in place that would allow the community of the CFRG to vote on the matter?

you sent me a request to replace Kevin as chair on Dec 20. I am reviewing the request and the related email threads, which is taking time, especially given the holiday period. I am also reading all the feedback on this list and feedback sent to me personally at [email-masked]. Let's please not invent new processes.

Lars Eggert
IRTF Chair

---

From: idontneedcoffee <[email-masked]>
Date: Sun, 29 Dec 2013 19:18:41 +0100

Agree, it would not "help" per se - but burning Kevin at the stake
because of his nsa mark would not
help either, since it would not really prevent any subversion
attempts(there are thousand ways
how powerful entities are influencing public organizations). But I guess
this is not what this initiative
is about. We're talking pure pr here - I took the recent publicity as an
opportunity to get more itsec*
people interested, but if you are right and the reaction to him staying
at his current post would be the
opposite - I agree with you, he should resign. I just joined so I'm far
from being able to weight-in the possible
consequences, I just wanted to point out that this situation can
actually be helpful if dealt with carefully
- and - due my near zero knowledge(as of today) about the inner workings
of cfrg I might have been
wrong.. or not..

have a nice day

idnc

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Dec 2013 19:12:54 +0000

My take on the proposition, as an individual, (*) intended
for Lars benefit.

- I don't think Dragonfly was mishandled in any important
way, nor is it at all important. I think that the proponents
involved in the dragonfly related discussions on both sides
have not helped by raising the temperature needlessly and
(it seems to me) in some cases quite deliberately. I would
discount pretty much all of the dragonfly related discussion.
(And as previously noted, the TLS WG are not progressing
their equivalent here, making the topic even less interesting.)

- I do think its valid to raise the question of NSA influence
given that NSA are reputed to be spending US$250M per year
("BULLRUN") to defeat Internet security mechanisms. That does
differ from the usual corporate axe-grinding that our processes
have been designed to counter. However, from what I can see so
far, our processes seem to be about as good a counter to
BULLRUN as can be done for the IRTF or IETF. (Asking the
question in the IETF as to whether we could do better would
be good, and I will bring that up after Lars has made his
decision here. I don't think discussion of that topic by those
ignorant of current processes is useful.)

- I do not think that the opinions of people who've only
appeared on this list for this discussion should be counted
as equivalent to those who have made ongoing contributions
to the IRTF and/or IETF. I'd weigh opinions from those active
in CFRG most, but only slightly ahead of opinions from those
with a general history of useful contribution to IRTF/IETF.

- I do not think that affiliation alone is a sufficient reason
to fire a chair, even given BULLRUN. While there is a "press"
downside to having Kevin as a co-chair, I think that is outweighed
by the overall damage that would accrue for firing a chair based
solely on affiliation. (In case its not clear from the above, I
see no other reason to remove Kevin as co-chair.)

- However, I do think that CFRG has not been as active as I'd
like to have seen in recent months, given BULLRUN and snowdonia
more generally. I would love to see ongoing detailed work within
CFRG as to how to counter pervasive monitoring. Right now, partly
due to CFRG inactivity, two other cryptography lists are highly
active, but with a lower SNR than I'd expect were CFRG participants
to try tackle the topic with sufficient chair involvement. This is
a criticism of all CFRG participants, not solely of the CFRG
co-chairs. However, the chairs do bear some additional responsibility
for list inactivity. (**) I assume that that lack of chair activity
is down to lack of cycles for the current chairs. If not, then
that might be useful (for Lars) to explore. I also assume that the
lack of general activity is mainly down to the same thing for other
participants. While I could imagine a universe in which people held
off from posting to this list because Kevin was a co-chair, I
have not seen any evidence of that having been the case. If that
has happened, then the people who didn't post on that basis should
say so (to Lars at least).

Overall, I do not think Kevin should be "removed" but I do
think that CFRG would benefit from an injection of energy,
possibly including via new or replacement chairs and I'd love
to see that energy devoted to working to counter pervasive
monitoring, to the extent that CFRG can help with that.

Lastly, I'm fine with Lars using his judgement on all of the
above, as IRTF chair, and I don't see any need to rush the
decision as to how to handle the request.

Hope that helps,
S.

(*) For those involved in this discussion who are not familiar
with how IETF/IRTF works, "as an individual" means that
since this is the IRTF, the fact that I'm an IETF security
AD shouldn't count, nor the fact that I co-chair the DTNRG.

(**) In saying that I take the blame similarly for a lack of
cycles to help chair DTNRG recently. And I already told Lars
I'd be happy to be replaced as DTRNG co-chair if/when he can
find a good alternative. That last is important too - new
co-chairs don't grow on trees. Ironically, the main reason
I've not had time for DTNRG is all the perpass stuff;-)

---

From: Tao Effect <[email-masked]>
Date: Sun, 29 Dec 2013 14:37:51 -0500

On Dec 29, 2013, at 4:09 AM, Eggert, Lars <[email-masked]> wrote:
> you sent me a request to replace Kevin as chair on Dec 20.

I think you have me confused with Trevor.

> Let's please not invent new processes.

If you followed the thread, you'll see that I almost immediately withdrew that suggestion upon learning that the IRTF doesn't vote.

Thanks,
Greg

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Dec 2013 13:12:16 -0800

On Dec 29, 2013, at 11:12 AM, Stephen Farrell <[email-masked]> wrote:

> . . .

> I would love to see ongoing detailed work within
> CFRG as to how to counter pervasive monitoring.

Wearing your perpass hat, how can CFRG help? I ask this because I have seen little on the perpass mailing list that indicated that an even minor problem has been lack of crypto, or the use of crypto that is thought to be breakable. What type of crypto research or assessment would help perpass?

Note that deprecating the use of crypto that is widely known to be broken is the purview of IETF WGs, not the CFRG. The relevant WGs (particularly TLS) seem to already be doing that.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Dec 2013 21:26:44 +0000

On 12/29/2013 09:12 PM, Paul Hoffman wrote:
>> I would love to see ongoing detailed work within CFRG as to how to
>> counter pervasive monitoring.
> 
> Wearing your perpass hat, how can CFRG help? I ask this because I
> have seen little on the perpass mailing list that indicated that an
> even minor problem has been lack of crypto, or the use of crypto that
> is thought to be breakable. What type of crypto research or
> assessment would help perpass?
> 
> Note that deprecating the use of crypto that is widely known to be
> broken is the purview of IETF WGs, not the CFRG. The relevant WGs
> (particularly TLS) seem to already be doing that.

One question might be whether some modes of operation are
really inherently more likely to have side-channels in their
implementation or not and whether the impact of that might
be practically usable by an attacker.

Another might relate to whether things like nonces might
provide a way for borked implementations to leak key bits
and if so, whether there are practical ways for susceptible
protocols to mitigate that, or bits of advice that should
be included in such protocol specs. (And finding some
susceptible protocols would be cool too if CFRG folks were
willing.)

I'm sure clever folk can come up with more once they start
to think about it.

S.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Dec 2013 17:11:37 -0500

>> assessment would help perpass?

Sending to perpass to get feedback on this question.

>> (particularly TLS) seem to already be doing that.

I don't agree with this assessment: the BCP Yaron Sheffer wrote on
depreciating RC4 got kicked
to the newly formed UTA WG, which has done nothing with it. The
biggest changes here have
been AGL pushing stuff into Chrome, but he can't do the server side
nearly as easily. It's been
a controversial topic in the TLS WG, even with Marsh Ray and AGL pushing for it.

> be practically usable by an attacker.

That assumes crypto is being used, and can hide the relevant information.
DNS is still in cleartext, and even HTTPS reveals what sites you are looking at.
The only fixes are PIR protocols, onion routing, and related tricks. We can also
try to reduce what is revealed: version numbers, configurations, and options can
be quite interesting for targeting, particularly if they are linkable
across sessions.

Side-channels are fixable with good, freely usable implementations: I
don't understand
why we are concerned with bad implementers. (Of course, the standard
needs to allow
a good side channel free implementation.) The lazy would rather copy
than innovate incorrectly.

Anyway, AES-GCM has side channel issues, but with HMAC+Salsa20/Chacha
or Chacha/Poly1305
it is easier to avoid them with as they have efficient circuits which
CPUs can do.

> susceptible protocols would be cool too if CFRG folks were

As in leak a key via the bits of an IV? That's not borked but
deliberate. For signing quite a few covert channels are known in
ECDSA. This is rumored to be an issue in the Test Ban Treaty negotiations,
but good luck finding out about that!

The easy countermeasure for some algorithms is to use nonces that are
implicit, incrementing with message number. That way
each peer enforces the algorithm on the other. Robert Ransom deserves
credit for this recognition AFAIK,
but I am sure this has been done before.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Dec 2013 18:57:56 -0800

On Dec 29, 2013, at 2:11 PM, Watson Ladd <[email-masked]> wrote:

> I don't agree with this assessment:

Then you maybe misunderstand the roles of RGs, WGs, and BoFs. RGs such as the CFRG do not get to write standards track documents (including BCPs), and yet these are the exact documents we want deprecating broken crypto.

> the BCP Yaron Sheffer wrote on
> to the newly formed UTA WG, which has done nothing with it.

As noted before, the UTA WG was just formed. RC4 has been broken for a long time.

> The

Many individuals in the IETF actively participate in more than just one WG. Even more passively watch. If the UTA WG fails to move on deprecating broken crypto, it will be seen by many interested individuals and that problem can be fixed later.

--Paul Hoffman

---

From: David McGrew <[email-masked]>
Date: Sun, 29 Dec 2013 22:20:06 -0500

Hi Watson,

I don't want to step into the middle of an argument, but I do want to 
address some particular points:

On 12/27/2013 06:56 PM, Watson Ladd wrote:
> The supposedly "open" CFRG had over the years atrophied, to the point 
> where the chair would think that no objection was equivalent to a 
> positive review. 

It is not fair to say that CFRG is "supposedly open".   It *is* open, 
certainly it is open to the extent that any IRTF RG is. Could it be more 
transparent in a way that helped to gain trust? Perhaps, and in this 
area, constructive criticism is welcome.   But everyone providing such 
criticism needs to understand the way that the IETF and IRTF work and 
make suggests that fit within that framework.   Furthermore, people 
should be willing to contribute their personal efforts to CFRG and IRTF, 
especially if they want to propose additional work items that will need 
to get done.

> As a participant, do you feel that that is an adequate foundation for 
> this WG's activities? 

I think that you mean CFRG, which is of course a Research Group of IRTF 
and not an IETF Working Group.   (I don't mean to sound pedantic, but 
there is a difference, and I don't want anyone who starts reading this 
thread in the middle to get the wrong idea.)

> the years it has been active? Do you believe that the CFRG has 
> increased the security of IETF produced protocols? Let's focus on the 
> issues here: the CFRG isn't doing its job. 

Yes, CFRG has done a good job over the years at providing a "forum for 
discussing and reviewing uses of cryptographic mechanisms, both for 
network security in general and for the IETF <http://ietf.org/> in 
particular" and "bringing new cryptographic techniques to the Internet 
community and promoting an understanding of the use and applicability of 
these mechanisms via Informational RFCs".   (The quotes are from the 
CFRG charter.)   I don't think that there is any question about that.    
On the Dragonfly protocol, the CFRG chairs could have done a better job 
at summarizing the diversity of opinion regarding a dead-end proposal to 
the TLS working group (dead end in the sense that the working group 
rejected it, so it didn't matter much what CFRG thought about it 
anyway).  But it is not fair to imply that CFRG has not been doing its 
job over the years because of that.   (Perhaps you didn't mean to imply 
that, but I can't quite tell.)

There could, and perhaps there should, be a discussion about what should 
be in the CFRG charter going forward.   If there are people qualified 
and willing to do more active work that polices the security of IETF 
protocols, we could do that.   Or perhaps it would be best to move some 
of the work out of the IRTF and into the IETF, if that would provide the 
group with more authority (e.g. a way to say "no" and make it stick).   
I would guess that the Security Area Directors would be open to 
suggestions.

David

---

From: John Bradley <[email-masked]>
Date: Mon, 30 Dec 2013 09:04:02 -0300

Lars,

People participate in the IETF/IRF as individuals.  Guilt by employer would be a dangerous precedent.

As one of the JOSE authors, we did bring a question to the CFRG re our spec not that long ago.  

If anything the problem with the CFRG is getting its members engaged rather than manipulation of the chairs.

I don't have any particular issue with Kevin or David both of whom I see at IETF meetings on a regular basis. 

Being a chair and motivating a group is not a easy task.   

That is however the criteria we need to be looking at for the too few volunteers we have for these positions.

On target discussions to help the chairs and RG are appreciated, but this has turned into a bit of a witch hunt.

While I may have opinions about the NSA and there activities, I don't consider those to have any special bearing 
on Kevin's competence.

Regards
John B.

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Dec 2013 11:06:11 -0800

On 12/29/13, 1:12 PM, "Paul Hoffman" <[email-masked]> wrote:

>Wearing your perpass hat, how can CFRG help? I ask this because I have
>seen little on the perpass mailing list that indicated that an even minor
>problem has been lack of crypto, or the use of crypto that is thought to
>be breakable. What type of crypto research or assessment would help
>perpass?

In the past I¹ve never considered CFRG a viable discussion forum for
making an impact by creating or approving new algorithms Š but if it is:

	We need an Œapproved' nonce-insensitive AEAD algorithm.

I¹m designing multicast communications in a mesh topology and CCM and GCM
suffer from N^2 complexity (since they require unique nonce/key).  Yes Š
there are ways that some link proposals like 802.1ae mitigate the issue
using device addresses as part of the key setup.  The best solution is a
nonce-insensitive AEAD.

We already have an RFC for SIV which is deterministic and a decent
solution, but it is not ŒNIST¹ approved, so I have problems introducing it
into consumer equipment.  It¹s also a little slow Š but I¹m not sure that
efficiency should be the primary evaluation criteria.

I¹ve asked NIST in the past and they have expressed no interest in the
problem.  It used to be very important for algorithms to be NIST approved.
 Do we need to find/create a new review and approval process for
algorithms that can be referenced by commercial products?

Paul

>
>Note that deprecating the use of crypto that is widely known to be broken
>is the purview of IETF WGs, not the CFRG. The relevant WGs (particularly
>TLS) seem to already be doing that.
>
>--Paul Hoffman