Re: [TLS] Dear @tqbf

[Patrick Mylund Nielsen <[e-mail]>]

On Fri, Nov 15, 2013 at 7:11 PM, Michael D'Errico <[e-mail]>wrote:

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

I agree with you both:

1. If you ridicule somebody for asking questions, you just maintain the
status quo. It's useless and annoying. The security industry is bad at
this; Cryptography in academia is much better, at least in my experience.

Nobody knows everything. There is no reason you should be ridiculed for
asking a question, even if you "are supposed" to know the answer.

However,

2. If people see your advice as authoritative, or you are implementing
cryptography in software non-recreationally/in something people will use,
you deserve all the flak you get if you don't actually know how to
implement it, or what you are talking about. Cryptography is just about the
worst arena for reckless experimentation.

If the response you are referring to was because of your question,

> Would it be possible to "fix" RC4 using this extension?  Simply insert a
random amount (at least 256 bytes) of pseudo-random padding at the
beginning of the first record sent using an RC4 cipher suite?

then this seems to be a clear example of #1. Without knowing what tqbf is
thinking, I would guess that he understood it as you suggesting it is done,
rather than simply asking a genuine question to understand if it's
possible. I know that a lot of the time he is responding to people who are
arguing, confidently, points they do not (even fundamentally) understand,
but which end up affecting (most often negatively) thousands of innocent
consumers.