Re: [TLS] Rethink TLS 1.3

Watson Ladd <> Thu, 27 November 2014 23:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CA2CA1A0127 for <>; Thu, 27 Nov 2014 15:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WaRhrWlrcZYm for <>; Thu, 27 Nov 2014 15:01:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B09DB1A0395 for <>; Thu, 27 Nov 2014 15:01:14 -0800 (PST)
Received: by with SMTP id 142so2505467ykq.12 for <>; Thu, 27 Nov 2014 15:01:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wzr/w8eHiAZiFW+0mXqUDVSfx5eQ6B2QzGpkknaJfic=; b=EMgryr9gVdaiKHPFlZLrlFcEzLDW1YF3HeNdLqdc8qpI95jrcM81WeaUC0giVyT64N kxyHjPrF0aOZNq2zyCHSDfBJYK2h28nE/Fr/ny9IGTBME0SO5GvNJeaiJuc3uNkRVBpy Mw4/W4az+UK2WKNP4aUt6jlR8kfADKfRUbCbK4h5uB1GOcgWVVW+GArawJACoiS+xx1i nRREkNImv0+u8uWieiIu4qDt+R+ToTYwoi3+IvyPSkBzaVjYdGO7/IjYmkm43UoMNzSh k+NFqkq0Xh6tNL8Mk852w/V9qfIcKTA/k+HGrh+TtwiIgCOFwsnVGyyrsJbqE3HQu8kT cZRw==
MIME-Version: 1.0
X-Received: by with SMTP id y5mr44649879yke.28.1417129273957; Thu, 27 Nov 2014 15:01:13 -0800 (PST)
Received: by with HTTP; Thu, 27 Nov 2014 15:01:13 -0800 (PST)
In-Reply-To: <>
References: <20141124105948.GH3200@localhost> <> <> <> <> <> <> <> <> <>
Date: Thu, 27 Nov 2014 15:01:13 -0800
Message-ID: <>
From: Watson Ladd <>
To: Nikos Mavrogiannopoulos <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] Rethink TLS 1.3
X-Mailman-Version: 2.1.15
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: Thu, 27 Nov 2014 23:01:16 -0000

On Thu, Nov 27, 2014 at 1:04 AM, Nikos Mavrogiannopoulos
<> wrote:
> On Wed, 2014-11-26 at 16:03 -0800, Watson Ladd wrote:
>> >> Parsing TLS is one of the biggest issues in implementations. I can't
>> >> promise to write the tool to auto-generate the parser, but we should be
>> >> sufficiently chastised by all those who tried and failed to parse TLS
>> >> records with handwritten C to consider not doing it ourselves.
>> > Where does this come from? TLS is one of the easiest protocols to parse.
>> OpenSSL couldn't parse an echo request correctly.
> This is a TLS extension and is known to be unnecessarily complex. It
> proves nothing about the TLS parsing complexity that you mention.

The construct of a heartbeat payload is a vector. It's simpler, not
more complex, than many structures in TLS.

>>  Many of recent CVEs
>> in OpenSSL have been related to corner cases in parsing. Microsoft got
>> bitten by a memcpy that didn't check its length. If it was easy to
>> parse, we wouldn't have parser bugs when parsing it. CVE-2014-3466
>> looks like a GnuTLS parser issue to me, and there are plenty of others
>> to pick from.
>> Who wrote the buggy code? Well, one Nikos Mavrogiannopoulos according
>> to git-blame. Maybe parsing TLS with handwritten C is not so easy,
>> after all.
> I believe you try to generalize based on your very limited view. Of
> course there will be bugs, and I guess there will be more by that author
> but there will not be any protocol that cannot be implemented
> incorrectly. However, you cannot prove your point in the complexity of
> TLS record parsing, by pointing to one parsing bug in the 14 years of a
> project. What does it make you think this is a recurring issue?

The fact that every single implementation I can think of has had RCE
or memory leak resulting from parsing errors, and usually quite a few?
This doesn't sound like an easy task: it seems downright difficult if
a lot of talented people can't do it. The Tor project is working on
writing parser generators that can deal with the sort of structure we
seem driven to produce in binary protocols for precisely this reason.

Contrast TLS to this, or In the first case I
chop out a header, and the rest is a message content: because
everything is fixed width except the last field, no tricky issues. In
the second case I can use yacc.

It's probably too late now, but we need to at least not make the problem worse.

Watson Ladd

> regards,
> Nikos

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin