[TLS] Dear @tqbf

[Michael D'Errico <[e-mail]>]

Dear @tqbf,

Here's a quick profile of the guy you're making fun of on Twitter:

I have a B.S. and M.S. in electrical engineering.

In 1993, I dropped out of the PhD program at UCSB to start an Internet
company back when nobody outside academia or the government knew what the
Internet even was.

Our first product was an email server.  If you exchanged email with anybody
using AT&T's Worldnet email service in the mid- to late 90's, then my code
delivered your messages.

Just before Netscape Communications Corp. went public they realized they
needed an email server of their own.  Instead of building one, they had us
create a Netscape-branded version of our product for them.

If you were to ask Eric Allman what his motivation to improve sendmail was
(also in the mid- to late 1990's), he'd have to say it was our product.  We
eliminated whole classes of security problems by not running as root, not
interpreting email addresses as programs to be exec'ed by a shell, and having
a whitelist of programs (e.g. procmail) that were safe for mail processing.
There's also the bits of not losing mail or needing the cryptic sendmail.cf.

Related to this working group, I was probably the first person to fully
implement TLS 1.2 and put up a server online for people to test against.
This server was instrumental in helping Opera, Microsoft, Apple, CryptLib,
and others hone their own TLS 1.2 code.

I was approached to help with the renegotiation bug, though I did not accept
due to the fact that they couldn't tell me what they wanted help with at the
time.  Once the issue became public, I did join the team in finding a fix.
During that time I implemented no less than three different proposals in the
test server.

Despite what the haters of that time called the "TLS WG DDoS" due to the
lengthy and often heated discussions, we did end up with an extension that
fixed the problem.  Fixed it for all versions including SSLv3.  Is fairly
easy to implement, and is deployed and protecting users in over 80% of
servers (according to SSL Pulse[1]).

     [1] SSL Pulse:  https://www.trustworthyinternet.org/ssl-pulse/

So, you can see that I'm an engineer and not a cryptographer.  Anybody who
follows this list regularly knows that.  That's why I ask questions about
cryptography subjects.  I always read the opinions of the cryptographers on
this list, so that I can better understand the concepts.  And I welcome the
participation of the newer arrivals to this group.

On the specific question about "fixing" RC4, up until yesterday I understood
that the problem with RC4 was bias in the first part of the keystream and the
fact that TLS didn't drop the first several bytes of output.  So, when I saw
that there was a proposal to add padding to TLS records BEFORE the data, to
fix a problem with CBC mode (unauthenticated padding), I correlated that to
the RC4 problem I was aware of and thought perhaps this unrelated fix could
ALSO fix the problem with RC4.

I would be negligent if I hadn't asked the question!  And if it actually was
possible to improve RC4 in a backward-compatible way with a simple padding
fix, wouldn't that be the very definition of awesome?

But you seem to want to create an atmosphere where people are afraid to ask
any question where the answer might be "no" lest you make fun of them behind
their back.  I appreciate the fact that some people called you out on it.

Your stance appears to be the common, "just implement AES-GCM" since we know
it's secure.  Well, that would be great, but requires TLS 1.2 to be
implemented, along with an entirely new cipher mode (AEAD).  And if you
haven't already done so, you need to implement TLS 1.1 as well since a server
might choose that version.  And you need to implement AES-GCM.  And while
you're at it, don't forget elliptic curve cryptography because modular DH
groups are slower and limited to 1024 bits and we really like EC math.

Now throw in the uncertainty of a "TLS 2.0 Specification Competition" and who
in their right mind is going to go down that path?  They'd probably hold off
on any TLS 1.2 implementation plan (if they even have one) and wait to see
what the world-wide crypto community comes up with.

Meanwhile the attacks are getting better and deployed code is showing its age
more and more.  One quarter of sites still accept SSL version 2, almost 70%
are vulnerable to BEAST, and 1/3 currently require your unloved RC4.  (Again,
see SSL Pulse for the stats.)  Partially this must be due to the fact that
RC4 was THE recommended cipher suite, above all CBC ciphers, for SSL 3.0 and
TLS 1.0, until very recently.

So the logical thing to do (according to you) is not even TRY to see if RC4
can be improved in the interim between now and two years from now when we
finally start seeing wide deployment of code implementing the winner of the
hypothetical TLS competition.  Makes so much sense.

For the rest of the working group, the point (note that I tried very hard NOT
to send this message; my apologies) is that if you have a question, no matter
how dumb Mr. Ptacek will think you are, please ask it.  At least one member
of this working group won't make fun of you.

Mike