Re: [TLS] Rethink TLS 1.3

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 27 November 2014 09:05 UTC

Return-Path: <nmav@redhat.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 159D51A88AF for <tls@ietfa.amsl.com>; Thu, 27 Nov 2014 01:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 era2WKGZWY8P for <tls@ietfa.amsl.com>; Thu, 27 Nov 2014 01:04:59 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB9E1A88BB for <tls@ietf.org>; Thu, 27 Nov 2014 01:04:52 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAR94okk019763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 27 Nov 2014 04:04:51 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAR94mJc016043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 27 Nov 2014 04:04:50 -0500
Message-ID: <1417079088.11680.7.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 27 Nov 2014 10:04:48 +0100
In-Reply-To: <CACsn0c=K0fBcQU3S5qv7yUtz+KP5vAQDpxVHKMwVpP_iS1tWHQ@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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/o6BnmGMM5hbOPQfe1nRLbmBRJxI
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
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: Thu, 27 Nov 2014 09:05:01 -0000

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.

>  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?

regards,
Nikos