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

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 21/12/2013 22:37, Hilarie Orman wrote:

> Is the CFRG co-chair the only person in the CFRG who has 
> associations, proclaimed or covert, with an organization intent on 
> undermining the standards process?

Given you admit Kevin works for an organisation intent on undermining
the standards process, why would you, or anyone (or even he) wish him
to remain as co-chair?

Kindly explain.

> Take it as a challenge, is the IETF smarter than NSA or any other 
> organization with ulterior motives?

Frankly: no. (Disquieting, I know.)

They are a billion-dollar-funded Nation State Adversary; this is a
mailing list.

We are at quite a profound disadvantage. Please be mindful of that.

> That open process provides the resilience against attack.

That open process is our only defense: but yes, it can be a powerful
one. And so, here we are, openly having this discussion.

When they're blatant, like Dual_EC_DRBG - or when they have an
@nsa.gov email address - we can spot it, if we actually take the time
to look.

But with something more subtle (mysterious 'seeds' with no
nothing-up-my-sleeve numbers, say), all bets are off. Without knowing
everything they know, really the best we can do is hope to spot which
bits look 'off'.

Based on what we've seen so far, they particularly seem to like:

• Subverting random number generators
• Specifying algorithms which need strong RNGs every time
• Standards which encourage implementations susceptible to timing and
  other side-channel attacks

We need to particularly watch out for those three. (Of course this
list isn't complete. I wish it were.)

I note the common thread: fragility. The results of their efforts are
often easy to implement poorly, very hard to implement well: who
implements slow constant-time Brier-Joye ladders for short Weierstrass
curves? [Raise your hands, please...] Who used deterministic nonces
with (EC)DSA? [...anyone *before* RFC6979?] That seems in line with a
paradigm of making things that could be secure, but usually aren't.

For future standards and primitives, if we can ensure that the right
way is more obvious, we can make our efforts more resilient, against
malice and mistake alike - hopefully.

> Can the IETF make sound technical judgments based on written 
> documents?

On technical cryptographic literature? That is the purpose of the
CFRG, surely.

They defer here, as Watson points out: so whomever represents the
opinions of here carries weight. For that weight of trust to fall on
untrustworthy shoulders is unsound.

> choose leaders based on their competence and not on their 
> employment.

The (reasonable) concern is that his employer deliberately wishes to
seed incompetence in crypto standards, so they can break them.

No 'purge' is necessary: you overstate. Having him on the group is not
an issue, as we are clearly well aware of his affiliations, and can
take his opinions with the trustworthiness and credibility that goes
along with them: as we should do with everyone, as you, Paul, and
Daniel quite correctly point out.

But as co-chair, in charge of stating - or, indeed, misstating! -
group consensus to others? Good grief, no. It seems untenable; more
importantly, untrustworthy. We cannot possibly do that with a straight
face after IETF 88, can we? Surely not. Surely, neither can he.

Kevin: Do you even have a comment on this? Anything? Any answer?

- -- 
/akr
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJStjmrAAoJEOyEjtkWi2t6oG4QAK/RTIFDBg3ZBW20QPXZiwcr
djONmK1Dp/q2JjFEWD2UggaJ6ZbMJ7GypXOh6XrtwrC9/eSSK8oUMJF5Q9o4qHH8
dnG4HC9Sn/bfKi/13ulTTJunV8SgIWtuHYq8u2C4ge2vDz9vGvNPDKdk0MmTrqwt
3fjO+RKKDd9aTUp2kIisVjH8M8P3f1yVD0QG+uR9svpgfpn11HCe8YMfLz3Ef89H
B+QAkpNzCZbASGP8wobCrDuIo0C+8gb0fjLA8H+ZSzBUJcQcSNOkHPblEN622+kS
od1bXKZCDx/AecbEfpRCYPR6obbs4DDJz7IcVRlcL4T2fKUIhFKN4xrFWmziA1JJ
vjvZRG+U+F1sAR2C7KngnCNtd88rhuJMXPYHM3my95jddAlif1D2G+Q5IAlmenxj
ovsenWm3ccJaWClBztA7EBK/KmzHkWvXuYfcYWLWR92xmJuObh0jMG3Bv0WyhrZF
1Zw33dnU1Puv/BxLgUl7yTu3eLy10bTgHu0NmtAYqcwvtj8ybeB1jQTtSRlGATFl
xeJj/qPvaR6KcfmNMke+BtQ1xDuvgQ7sWfxbUe5w6NvVNOPf/6egBxZAw9DtOjLT
MzsSBOuxTbOHwY8pgMDTRnM8vN/oUm5bmSR5Ht1TPZnML4sJ/tYNCjYHhUFPSWW2
6MCN2kL41EEeqcdEFKQI
=uiKj
-----END PGP SIGNATURE-----