Re: [TLS] TLS 1.3 process and consensus

Daniel Kahn Gillmor <> Thu, 27 March 2014 19:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 16C9C1A037E for <>; Thu, 27 Mar 2014 12:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dEodAS9Fbpgv for <>; Thu, 27 Mar 2014 12:13:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DB9641A0303 for <>; Thu, 27 Mar 2014 12:13:35 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id D898EF984 for <>; Thu, 27 Mar 2014 15:13:32 -0400 (EDT)
Message-ID: <>
Date: Thu, 27 Mar 2014 15:13:20 -0400
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: "" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6+git0.20140323
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="DpTBFG4jQiQA3tJ2uLba4U3gbc0XlUJmp"
Subject: Re: [TLS] TLS 1.3 process and consensus
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: Thu, 27 Mar 2014 19:13:43 -0000

On 03/27/2014 01:51 PM, Watson Ladd wrote:
> I think we should try to understand the design space for TLS 1.3 in
> greater detail by enlarging the number of proposals under
> consideration before we commit to a process of local optimizations.
> Even more clarity from the WG chairs on the process would be welcome.

I think some gathering of general opinon is a good idea, as long as it's
clear that we're establishing metrics by which we might judge a future
implementation and not absolute requirements.  Some of the things that
people generally want could come into conflict, and then proposals about
what the future TLS 1.3 would be will be assessed by how well they meet
the various, possibly-conflicting goals.

I note that we don't appear to even *have* full consensus on any of the
proposals raised thus far: all-PFS, no-Compression, all-AEAD, though i
get the general sense that most people are OK with each of them.
Likewise, we have some rough goals for TLS 1.3 as expressed in the
charter, like minimizing round trips and keeping as much of the
handshake encrypted as possible.  I'd be happy to see us try to add some
sort of resistance to traffic analysis as a goal as well, though i
recognize that there are bandwidth and latency and computation concerns
there.  And while i'm listing my ponies, I'd also like to see us end up
with a spec that is amenable to theoretical security proofs based on
reasonable models of known attacker capabilities.

But if gathering the sense of the group on these points means that we've
painted the process into a corner whereby no proposal (however good)
that doesn't meet condition X will possibly be considered, then i think
we've done the WG (and the community that relies on it) a disservice.
We should be gathering these goals as metrics to measure a complete
proposal against, not as a strict litmus test or as a way to cobble
something together.

That said, it's possible that there are some absolute WG constraints for
a future TLS 1.3.  For example, we might require that the TLS 1.3
initial handshake stage be backward-compatible with earlier TLS
handshakes, so that it can be run over the same port as TLS 1.2 without
conflict for those servers and clients that choose to implement multiple
versions of TLS.  (Can this constraint be phrased more precisely so
proposals can verify their compliance with it?)

This constraint seems guaranteed to hobble any more radical designs
(for example, i think it rules out any server-speaks-first protocol),
but may be the only realistic outcome in the context of this WG;
otherwise people could just refocus their work on entirely different
protocols (e.g. QUIC).

I think we would do well to explicitly state any hard requirements we
actually have, alongside any articulable goals, and then encourage
people to submit full protocol specifications for the group to review
against these requirements and goals.

Those specifications might change between revisions, and maybe a new
spec will arise that uses good ideas from other specs; but assembling
the full spec piecemeal from the beginning seems like a way to end up
with the kind of patchwork that has bitten us several times in the last
several years.

So, are these things Requirement, Goal, Dont-Care, or Do-Not-Want?

from my perspective:

Handshake-Interop-with-TLS-1.{0,1,2}: Requirement
All-PFS: Goal
Avoid-Compression: Goal
All-AEAD: (i think this is too unclear to say, see Russ' question)
0-RTT-Capable: Goal
Minimize-Latency: Goal
Traffic-Analysis-Countermeasures: Goal
Theoretically-evaluable: Goal
Encrypted-Handshake: Goal
Algorithm-Agility: Goal

I'm sure there are other axes of the design space that i'm not listing
here.  I'd love to see people make concrete proposals for TLS 1.3 that
we could evaluate against them, even if they can't succeed on all fronts.