Re: [TLS] Rethink TLS 1.3

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Fri, 28 November 2014 11:19 UTC

Return-Path: <ryan-ietftls@sleevi.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0C1A1B29 for <tls@ietfa.amsl.com>; Fri, 28 Nov 2014 03:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_pROakI_XT4 for <tls@ietfa.amsl.com>; Fri, 28 Nov 2014 03:19:54 -0800 (PST)
Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EADA61A1B0E for <tls@ietf.org>; Fri, 28 Nov 2014 03:19:53 -0800 (PST)
Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 99D96BBA06C; Fri, 28 Nov 2014 03:19:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=jcTXcNuG0YEk/rW4FSkP4jCMraE=; b=ugOpF/1Upi7CF/jbB gYGEeUB+pdcGIjHDryIV/ebhDVOCkntGrA5zf2BmsnnZWJwjcfXLhtHOYog3ViRU fxgxO6B+nKKv6P2A+tfA5tkvlhfYtoiVsb0FMYG0Mq7sacmEU7XoqGVg+TaUA65e 5F39ppHS9PLasa84dDCN5qXHdU=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 4F8E2BBA06A; Fri, 28 Nov 2014 03:19:53 -0800 (PST)
Received: from 74.125.57.233 (proxying for 74.125.57.233) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 28 Nov 2014 03:19:53 -0800
Message-ID: <297be8cca9e6e8bfc31b930610f12743.squirrel@webmail.dreamhost.com>
In-Reply-To: <CACsn0cnAYgWeXmH3mTd9v=jVXYX70trOhdQxv4hsFk=OxD48bg@mail.gmail.com>
References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <CACsn0ckcpNYJbnb+vd=nazXQhN5m3=L1DxO+KnLXMVyWOQ-PUQ@mail.gmail.com> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <CACsn0c=7fzAmshr7qamiLZdRUNs8kexQPR4E6n3teqNi4HzOjQ@mail.gmail.com> <CAOgPGoAEyH4MRAjGHyUg1c9PuY2c6SmfB+6jgBegRi6dvVchDQ@mail.gmail.com> <CACsn0ckqZOf7mrXsjcCh0NGx=MDyoAcK7GT+_TxFe1Do7Xtuyw@mail.gmail.com> <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.com> <CACsn0c=K0fBcQU3S5qv7yUtz+KP5vAQDpxVHKMwVpP_iS1tWHQ@mail.gmail.com> <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com> <CACsn0cnAYgWeXmH3mTd9v=jVXYX70trOhdQxv4hsFk=OxD48bg@mail.gmail.com>
Date: Fri, 28 Nov 2014 03:19:53 -0800
From: "Ryan Sleevi" <ryan-ietftls@sleevi.com>
To: "Watson Ladd" <watsonbladd@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gSvimrfAsp_cMmRVSpXd2P61jLQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Rethink TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ryan-ietftls@sleevi.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 11:19:59 -0000

On Thu, November 27, 2014 3:01 pm, Watson Ladd wrote:
>  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 http://curvecp.org/packets.html, or
>  https://tools.ietf.org/html/rfc2812#section-2.3.1. 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.
>
>  Sincerely,
>  Watson Ladd

Watson,

I don't think this argument is particularly germane, fruitful, or frankly,
entirely well reasoned. Your argument that it's a protocol issue because
there are implementation issues lacks consideration that implementation
issues exist regardless of the protocol. At best, you're writing a screed
against parsers in C, and while I suspect you'll find a receptive audience
to this particular idea, the TLS WG is not the place for it.

As a simple counter-point to your reasoning, consider the many (MANY) RCE
bugs in msasn1.dll or cryptologic bugs such as the (poorly named and
technically inaccurate) BERserker bug in NSS. ASN.1 is very much a
structured representation for which one can create static representations
of that lack any form of dynamic parsing. Indeed, many early ASN.1
implementations used exactly this - parsing the ASN.1 definition and
generating static parsers that were "bug free", in as long as the parser
generator was bug free. This is the same thing Tor is doing. There are a
number of deficiencies in doing so, and implementors moved away from it,
and as a result, many bugs when processing ASN.1 were introduced. However,
this is not an intrinsic property of ASN.1, but of how implementors have
chosen to implement.

Hopefully this will be the end of the discussion of this vein on the list.
I see Nikos has already explained why the Heartbeat construct was itself
exceptional and, ostenstibly, non-idiomatic and error prone. That does
not, however, apply to the entire protocol, and one can arguably write
non-idiomatic and error-prone structures in the majority of parsers out
there, but that doesn't mean we're all doomed to invent Yet Another Parser
Language.

If anything, your argument is best reduced to a "fixed width field"
argument, which has its merits, but also lacks any form of extensibility.
While some may see that as a Good Thing, I would suggest that the majority
do not view "lack of extensibility except via protocol update" to be an
inherently valuable trait.

Cheers,
Ryan