On 6/09/13 04:50 AM, Peter Gutmann wrote:
"Perry E. Metzger" <pe...@piermont.com> writes:

At the very least, anyone whining at a standards meeting from now on that
they don't want to implement a security fix because "it isn't important to
the user experience" or adds minuscule delays to an initial connection or
whatever should be viewed with enormous suspicion.

It isn't the whiners that are the NSA plants, but the people behind them, egging them on, while also mounting attacks on the competent honest ones to confuse and bewilder them.

I think you're ascribing way too much of the usual standards committee
crapification effect to enemy action.

The general process is first to push the group into crap, and then to influence it with competence. In order to influence, the group's own competence must be neutralised first.

For example I've had an RFC draft for a
trivial (half a dozen lines of code) fix for a decade of oracle attacks and
whatnot on TLS sitting there for ages now and can't get the TLS WG chairs to
move on it (it's already present in several implementations because it's so
simple, but without a published RFC no-one wants to come out and commit to
it).  Does that make them NSA plants?  There's drafts for one or two more
fairly basic fixes to significant problems from other people that get stalled
forever, while the draft for adding sound effects to the TLS key exchange gets
fast-tracked.  It's just what standards committees do.

And, controlling processes is just what the NSA does.


The process of an inside takeover is well known in *certain* circles. It only takes one or two very smart competent people to take down an entire organisation. The mechanisms might well be described as crapification then exploitation.

This is not to say that the IETF WG chairs are NSA plants, nor that all or any particular IETF committee is sunk. Rather, it is to say that it is very difficult to stop a committee being hopeless, and it's rather easy to tip a good committee into it.

(If anyone knows of a way of breaking the logjam with TLS, let me know).

In contrast, it is not well known how to repair the damage once done. The normal method is to abandon ship, swim away, build another ship with 1 or 2 others.



The cryptography mailing list

Reply via email to