Re: [TLS] Rethink TLS 1.3

Nico Williams <> Mon, 24 November 2014 10:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9B5D91A1EFD for <>; Mon, 24 Nov 2014 02:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pAwB5rMyoU-I for <>; Mon, 24 Nov 2014 02:37:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DC38E1A1EEF for <>; Mon, 24 Nov 2014 02:37:49 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id A771B50808E; Mon, 24 Nov 2014 02:37:49 -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=/I+TNvKHb5nGai 1YG8f1mlQ6eBA=; b=k9xyYLGa8Vgln78OriG/TBganlDORe4aEUZHrNHoMwJdHg KZIZb4sMZJbl7jaSxNlV6A1nkMi/hw/lar0G0JlW5p+QNu8XANaz5h6pt5rSD1K5 gp7+jmQgcRqKXhWnwF04uoGzwk8FelXUb+azeWHStbvF95VPpM9tBvf39FLKE=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 46F61508072; Mon, 24 Nov 2014 02:37:49 -0800 (PST)
Date: Mon, 24 Nov 2014 04:37:48 -0600
From: Nico Williams <>
To: Ralph Holz <>
Message-ID: <20141124103747.GD3200@localhost>
References: <> <> <> <>
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 10:37:50 -0000

On Sun, Nov 23, 2014 at 02:27:25PM +0100, Ralph Holz wrote:
> I'd disagree with the notion of "it is clear what TLS supports" - there is
> no threat model describing the strength of an attacker (and there never has
> been). It's not even clear what TLS means by "authentication".

This is true, and it is partly why we need algorithm agility: to
trade-off performance/cost for security in a context-sensitive manner.

Network security is an extension of physical security (if your hardware
or the software it runs aren't secure...).  If we assume physical
security (a big assumption) then we can get perfect security at very
high cost: e.g., every communicating pair of nodes meets physically to
securely exchange one time pads.  But we know that's too costly (it
doesn't scale, for one), so out the window goes perfection.  Everything
we're doing (DNSSEC, DPRIV, CT, ...) is just an exercise in
asymptotically approaching perfection.

> As a possible step forward, we could say TLS supports authentication as
> Lowe's injective agreement - a fairly strong definition yet one matching
> intuitive expectation.

That's implied in the Internet threat model, really.  We should make
some things more explicit, of course (e.g., we need liveness).  Of
course, in some cases we are willing to trade some features off (e.g.,
certificate status freshness tolerance vs. performance, or 0-RTT early
data transmission).

See above about trade-offs.