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
- [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Eric Rescorla
- Re: [TLS] Rethink TLS 1.3 Henrick Hellström
- Re: [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Henrick Hellström
- Re: [TLS] Rethink TLS 1.3 Hanno Böck
- Re: [TLS] Rethink TLS 1.3 Henrick Hellström
- Re: [TLS] Rethink TLS 1.3 Ralph Holz
- Re: [TLS] Rethink TLS 1.3 Jeffrey Walton
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Henrick Hellström
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Henrick Hellström
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Florian Weimer
- Re: [TLS] Rethink TLS 1.3 Martin Rex
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Martin Rex
- Re: [TLS] Rethink TLS 1.3 Martin Rex
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Salz, Rich
- Re: [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Brian Smith
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] Rethink TLS 1.3 Yoav Nir
- Re: [TLS] Rethink TLS 1.3 Hubert Kario
- Re: [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Hubert Kario
- Re: [TLS] Rethink TLS 1.3 Bodo Moeller
- Re: [TLS] Rethink TLS 1.3 Joseph Salowey
- Re: [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Peter Gutmann
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] Rethink TLS 1.3 Ilari Liusvaara
- Re: [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] Rethink TLS 1.3 Watson Ladd
- Re: [TLS] Rethink TLS 1.3 Peter Gutmann
- Re: [TLS] Rethink TLS 1.3 Nikos Mavrogiannopoulos
- Re: [TLS] Rethink TLS 1.3 Ryan Sleevi
- Re: [TLS] Rethink TLS 1.3 Nico Williams
- Re: [TLS] Rethink TLS 1.3 Peter Gutmann