Re: [TLS] Dear @tqbf

[Marsh Ray <[e-mail]>]

We love you Mike but you left out the part about:

* you implementing an entire TLS stack from scratch

* your experiments analyzing SHA-N performance on FPGAs, and

* that time we sat at the banquet table at Defcon and hacked the conference badge embedded system and brute forced the all the ninja party invite codes and posted them online and when we went to the party the badge scanner had been shut down thus exposing that the real party invites were paper based and the whole thing was just security theater.

@tqbf was being a sarcastic ass. He was making fun of the entire WG, not just you specifically. If he's really so smart he'd show up here and offer one useful contribution for every 9 darts he throws.

- Marsh
Usual disclaimers apply.

P.S. I thought the question you posed about RC4 was entirely appropriate.



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Michael D'Errico
> Sent: Friday, November 15, 2013 4:11 PM
> To: TLS Mailing List
> Subject: [TLS] Dear @tqbf
> 
> 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls