Re: [TLS] Rethink TLS 1.3

Ilari Liusvaara <> Wed, 26 November 2014 10:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CB3D91A00A6 for <>; Wed, 26 Nov 2014 02:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E-gI4baqxgqk for <>; Wed, 26 Nov 2014 02:42:02 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DD651A8A3E for <>; Wed, 26 Nov 2014 02:42:00 -0800 (PST)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 98C478184F; Wed, 26 Nov 2014 12:41:57 +0200 (EET)
Date: Wed, 26 Nov 2014 12:41:57 +0200
From: Ilari Liusvaara <>
To: Watson Ladd <>
Message-ID: <20141126104157.GA13375@LK-Perkele-VII>
References: <20141124105948.GH3200@localhost> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <>
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: Wed, 26 Nov 2014 10:42:05 -0000

On Tue, Nov 25, 2014 at 02:19:53PM -0800, Watson Ladd 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.

The parts of TLS 1.3 that worry me the most are:

- Ensuring that implementations don't screw up the 2RTT case.
- Certificate authentication.

And yes, both worry me much more than key exchange.

Both are quite nasty problems, because it is difficult to capture
those in security model. And without security model, there can be no
security proof.

The certificate authentication is practicularly nasty because of the
interactions with TLS 1.2 certificate authentication (see the recent
message) and interactions with applications.

And yes, the current server authentication, the current client
authentication and the proposed client authentication via update all
have problems here.

E.g. With current scheme, trying to resume client-authenticated session
can go wrong. And the new scheme can have weird interactions with
applications if client authenticates midway.