Re: [TLS] Rethink TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Thu, 27 November 2014 00:03 UTC

Return-Path: <watsonbladd@gmail.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 282D51A8866 for <tls@ietfa.amsl.com>; Wed, 26 Nov 2014 16:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl3tR-g3CmY6 for <tls@ietfa.amsl.com>; Wed, 26 Nov 2014 16:03:22 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BE21A1DE2 for <tls@ietf.org>; Wed, 26 Nov 2014 16:03:22 -0800 (PST)
Received: by mail-yk0-f182.google.com with SMTP id 131so1754079ykp.27 for <tls@ietf.org>; Wed, 26 Nov 2014 16:03:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cI8QLhDd/scXwn3uoMvWVdr/lIfgYfxDpk+YwOsNirc=; b=hknYLH/WguXTzhJdzpNhWX7fZwqdyeRbh5YvuQ6f/gRic4AmPXJCRrTKSMExMms3Mf h0gy5prjGIeR3Jj1yWtL4UjzRv2Xc7WZnISCwruia1sX+JX3TUFQa8LwnrKuWb+l4y3V 8fpncTofLxVmnPvuS1FxC7xad4Dku4F+9E3NeIvurJY7arNBfELXPRYeo8ZAxd6rmPXL G6AxBKflpEVv3SI0kQjLCewC/FpMHHiLPuCcbXUeHB3Fete1Mw8apZjRS6MF1bZ5JeRF mfuuXeTxhxuop920H3Ii/HqqjXkwgQcFPIOnaOgKOF84O84unq1EYdB/5xtABRummtmP KdjQ==
MIME-Version: 1.0
X-Received: by 10.170.100.215 with SMTP id r206mr39581824yka.19.1417046601807; Wed, 26 Nov 2014 16:03:21 -0800 (PST)
Received: by 10.170.195.21 with HTTP; Wed, 26 Nov 2014 16:03:21 -0800 (PST)
In-Reply-To: <24500329.3561152.1416988006072.JavaMail.zimbra@redhat.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>
Date: Wed, 26 Nov 2014 16:03:21 -0800
Message-ID: <CACsn0c=K0fBcQU3S5qv7yUtz+KP5vAQDpxVHKMwVpP_iS1tWHQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/h8PdtYuZ5mi75O5Uk1rU4WpGU30
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 00:03:24 -0000

On Tue, Nov 25, 2014 at 11:46 PM, Nikos Mavrogiannopoulos
<nmav@redhat.com> wrote:
> ----- Original Message -----
>> On Nov 25, 2014 1:10 PM, "Joseph Salowey" <joe@salowey.net> wrote:
>> As for improvents, how about finding an existing, conservatively designed
>> signature based key agreement mechanism with the right properties, and
>> using it? The current proposal has two distinct client auth mechanisms, one
>> in the handshake and the other in update.
>
> That does not need to be in TLS 1.3. New ciphersuites can be defined independently.

Options add complexity, and while OPTLS had some compelling
advantages, it's likely that whatever scheme ultimately is adopted
will be good enough.

Right now TLS 1.3 makes many big changes from TLS 1.2. This increases
the minimum complexity of an implementation that has to do both.
Adding a simpler option doesn't help matters, unless a complex option
is removed. The result of this complexity is that it is harder to test
the code that runs, and harder to analyze the implementation for
correctness.

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

Sincerely,
Watson Ladd

>
> regards,
> Nikos

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