[Cryptography] The role of the IETF in security of the Internet: for or against the NSA? for or against the security of users of the net?

[Watson Ladd]

On Tue, Jul 22, 2014 at 12:46 PM, Stephen Farrell
<stephen.farrell at cs.tcd.ie> wrote:
>
> Ian,
>
> On 22/07/14 11:11, ianG wrote:
>> The discussion is not over with Russ' draft, but the discussion is over
>> with TCPinc.
>
> That's rhetorical rubbish frankly. But you're as free to
> participate as to not and we'll see how (un)successful
> TCPinc ends up. In my experience its pretty hard to predict
> the future anyway.
>
> And FWIW I also disagree with your assertions about TLS etc.
> but its not really worth a blow-by-blow disagreement. There
> is clearly an element of truth in the assertion that things
> like the IETF are less good at inventing stuff, and are
> better at improving and maintaining already-good things (when
> stuff goes well, which it doesn't always). Its fine that we
> disagree about that but you're exaggerating IMO.

It really isn't: trying to add curve25519 to TLS has turned into a process with
no end in sight, because Microsoft has provided an alternative to
twisted Edwards curves of slightly different
twisted Edwards curves. For all the talk of "rough consensus and
running code" TLS 1.3 has been very controversial,
and with very little running code.

The agility in TLS was useless: both options were fatally flawed, and
this was documented in the RFC.
Similar flaws were documented in early IPsec versions earlier that
year. It took 14 years to fix this bug.
The downgrade to SSLv3 was known from the start, and wasn't fixed until now.

Tcp encryption was demonstrated: it shouldn't be that hard to start
with what was implemented and demonstrated.
Yet the WG can't get its charter together, and I have no idea what
that conversation is about. How many of the people
on that list write TCP stacks?

ECC for PGP is still not implemented by anyone other than a recent
in-browser(!) javascript implementation.
OpenPGP is unanalyzable, and PKIX is PKIX.  The complexity of PKIX is
particularly painful as it puts a lot of nasty
(usually C) parsing code into the TCB.

DNSSEC has been in the works for longer than I have been alive. It
still isn't deployed. Despite two email encryption standards,
S/MIME and PGP, most email is unencrypted. Even using the mail
provider as a PKI, or having a file of email public key pairs
would solve this problem. The file wouldn't even be that big compared
to the English Wikipedia.

Of the three IETF protocols I've found for establishing connections
between two parties authenticated with public keys, the only
one that is correct is the one no one uses, and the most important one
is the worst one. The IETF has never taken cryptography
seriously: the channel binding drafts are based on a misunderstanding
of what key protocols can promise, and in fact require
an impossible protocol (two-party fair coinflip) to be completely secure.

I've found major errata in RFCs documenting algorithms. Guidance on
implementations is nowhere to be found. It takes work to
do this badly.

This is not confined to the security area: NFS vs. 9p is instructive.

Most of the innovation in security tools is happening outside of the
IETF, even when it could benefit from standardization as a means
to ensure multiple implementations and to drive more adoption.

Sincerely,
Watson Ladd



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