Re: [TLS] Rethink TLS 1.3

Nico Williams <> Mon, 24 November 2014 19:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F8041A89F2 for <>; Mon, 24 Nov 2014 11:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oQyXpScvwI7P for <>; Mon, 24 Nov 2014 11:58:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E155B1A895A for <>; Mon, 24 Nov 2014 11:58:43 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id A924120058D85; Mon, 24 Nov 2014 11:58:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=nSecLQZLcCkwOb eQdoZJ1l9vss0=; b=mse9UD5BA9Sbt1G/GRXgjBlwXl+KSgJMnBr9emh4YBTng+ 16ibeWC8Rd9UasVHb/OPzszuJTg3pRtdD679vS3CRJ/+kB0bTGq6I/Xmc8Lf0+uU wyRFH7Bakb+I49pOdWxRLlhc9w9dB/3xFN4zYJEAcA7qRhfUOsh/zhefXyn2w=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 565D220058D84; Mon, 24 Nov 2014 11:58:43 -0800 (PST)
Date: Mon, 24 Nov 2014 13:58:42 -0600
From: Nico Williams <>
To: Brian Smith <>
Message-ID: <20141124195840.GP3200@localhost>
References: <20141124170257.GJ3200@localhost> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "" <>
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: Mon, 24 Nov 2014 19:58:45 -0000

On Mon, Nov 24, 2014 at 11:27:12AM -0800, Brian Smith wrote:
>                 [...]. In particular, we should recognize that the
> "conservative" approach of making minimal changes to address
> individual issues has negative consequences. Further, the

Yes, and the session hash I-D takes that approach.

> renegotiation flaw, BEAST, CRIME, Triple Handshake, etc. all should be
> seen as evidence that the development model for TLS should shift to
> one that is likely to preempt unknown attacks, instead of one that
> reacts to attacks.

Well, yes, but I think we need to subject TLS 1.3 to the sort of
security analysis that is generally done for cryptographic algorithm

And the I-D and RFC really needs to include a security analysis where
conceivable attacks are described, with text explaining why the attack
does not work on TLS 1.3.  Appendix F is a bit light-weight at this

We can easily provide this for all attacks that have worked in the past
against TLS and similar protocols.  Finding new attacks is the fun
(difficult) part.

> > Please stop claiming that providing so much control to an attacker
> > as something that is (or should be) normal, rather than considering
> > providing so much control to attackers as what it really is:
> > a huge and gaping vulnerability in Web-Browsers and in the
> > (lack of a) Web Security Model.
> Attackers having that level of control is normal for people who build
> software for the web, which is a very large group of people in the TLS
> community. Ultimately, this means that adaptive chosen plaintext
> attacks and other negative consequences of the web security model are
> well within scope.

And should be.  Since otherwise the applicability of TLS would be quite
constrained, and it'd be quite difficult to ensure that all uses of TLS
are within those constraints.

To make TLS 1.3 useful it must be secure relative to adaptive chosen
plaintext attacks, and anyways, we can't fix the web security model at
this layer.