Subject: [TLS] Dear @tqbf

From: Michael D'Errico <[email-masked]>
Date: Fri, 15 Nov 2013 16:11:27 -0800

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

---

From: Patrick Mylund Nielsen <[email-masked]>
Date: Fri, 15 Nov 2013 20:24:49 -0500

> of this working group won't make fun of you.

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.

---

From: Marsh Ray <[email-masked]>
Date: Sat, 16 Nov 2013 02:44:54 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael D'Errico
> Sent: Friday, November 15, 2013 4:11 PM
> To: TLS Mailing List
> Subject: [TLS] Dear @tqbf
> 
> Dear @tqbf,
> 
> company back when nobody outside academia or the government knew
> what the Internet even was.
> 
> 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]).
> 
> 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
> 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
> 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
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Bryan C. Geraghty" <[email-masked]>
Date: Fri, 15 Nov 2013 22:52:55 -0600

Mike, 

I respect your past contributions. However, I recommend the next time you
get heated, you walk away from the keyboard. Yes, Tom was being sarcastic
but this is no better; possibly worse. I tried to pick apart all of the
rhetoric you employed in your post and couldn't take it anymore. 

What this all comes down to are these points:

* You have a lot of valuable experience implementing TLS but don't fully
understand the crypto
* Tom and his team have a lot of experience breaking crypto and protocols
* TLS is crumbling under improving analysis & attacks
* Other people on this list are arguing (not just asking) about things that
were proven 10 years ago

Where do we go from here?

Bryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marsh
Ray
Sent: Friday, November 15, 2013 8:45 PM
To: Michael D'Errico; TLS Mailing List
Subject: Re: [TLS] Dear @tqbf

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

> 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.
> 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]).
> 
> 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.
> 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
>