Subject: [TLS] TLS 1.3 process and consensus

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Mar 2014 13:51:50 -0400

Dear all,

I cannot count myself as among the supporters of the consensus calls
that the leadership has recently issued for a very simple reason: TLS
1.3 does not exist, and therefore to consider the consequences of
changes to it is impossible. As good as the ideas are, to judge
features in isolation is to end up with a Baroque monstrosity.

Behind such pedantry is a serious point: TLS 1.3 has quietly become
TLS 1.2 with some features removed, and maybe a few new flows. As
such, the final product will be heavily influenced by design decisions
inherent in the choice of direction the TLS WG leadership has made,
with very little discussion from the membership about these choices.
None of us has the knowledge of the TLS ecosystem to design an
acceptable solution individually.

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.

SIncerely,
Watson Ladd

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 Mar 2014 15:13:20 -0400

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

	--dkg