Re: [TLS] Dear @tqbf

"Bryan C. Geraghty" <> Sat, 16 November 2013 04:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53A8811E8175 for <>; Fri, 15 Nov 2013 20:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.696
X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q0=0.303]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zcjpijj28swO for <>; Fri, 15 Nov 2013 20:52:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D27F211E8168 for <>; Fri, 15 Nov 2013 20:52:56 -0800 (PST)
Received: by with SMTP id i4so4965530oah.10 for <>; Fri, 15 Nov 2013 20:52:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=Ne2YzX3tF10NDznIyTYCPymZNuY3Elh4o+mjZLbaXw4=; b=S/ppwqr9nmW9oqbuWZXfeJMkLN/SyAB5439nPiBrAOctXanMc9wI7bfxUWIlJ40Qlg gHGxvcim8cjmnHIe09Zeapok/bnSeK6T6lc9CCQR5AmpQcqne390HYfxRfCTOnzEHt4t UFQt3iIe4Xn05S/MwPmgN8SEcxP+U6l9MXsYB7XazpNNKVn+CSc48kwreyhM++51ITKO urv0RegcXYOkIQOFAdiK2qS/a2kB54dwUr6dzWkQa1bppWtvwSJrQwbhZfJuFx/4nXpR BwuYrHqzCchCBjoWjNzjBRusXPG2awUmDhe3ZxSbQsXcI/7+3AOVP/CuXdTrHCr2yyqG hN0A==
X-Gm-Message-State: ALoCoQl8PnAmg/aP/unoXAbptl4WhiVcQN//ejB8UnMHnPIXYD7wn1c0va4M+2hqAEVp54xO6cqm
X-Received: by with SMTP id ub9mr10058207oeb.39.1384577576236; Fri, 15 Nov 2013 20:52:56 -0800 (PST)
Received: from Genie ( []) by with ESMTPSA id r6sm8244048obi.14.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Nov 2013 20:52:55 -0800 (PST)
From: "Bryan C. Geraghty" <>
To: "'TLS Mailing List'" <>
References: <> <>
In-Reply-To: <>
Date: Fri, 15 Nov 2013 22:52:55 -0600
Message-ID: <001e01cee287$b759c8a0$260d59e0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHO4mB29zTAF07uGE+mDu8vfSccL5onH3UQgAAXjoA=
Content-Language: en-us
Subject: Re: [TLS] Dear @tqbf
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Nov 2013 04:53:01 -0000


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?


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

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: [] 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
> 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
> 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:
> 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
> 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
> 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
> 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
TLS mailing list