Re: [TLS] Bakeoffs

[Trevor Perrin <[e-mail]>]

On Wed, Apr 16, 2014 at 3:53 PM, Alyssa Rowan <[e-mail]> wrote:
>
> On 16/04/2014 01:46, Trevor Perrin wrote:
>
>> Maybe this argues for Adam Langley's earlier suggestion (also
>> endorsed by a few others) that we focus on a TLS 1.3 that is a
>> "tidying up" of 1.2, and push the larger goals (e.g. redesigning
>> handshake for lower-latency or more encryption) to a TLS 2.0?
>
> On reflection, I think I may favour this approach, yes:
>
> * Keeping TLSv1.3 a cleaned-up v1.2 with better, faster, forward-secure
>   baseline of fast, constant-time ECDHE and AEADs, legacy/broken lint
>   removed, bugs fixed and downgrade protection, and getting that out
>   fairly promptly;
>
>   and,
>
> * Following that with a TLSv2.0 process in which we look at the far
>   more radical and challenging changes: handshake improvements,
>   ClientHello/SNI encryption, perhaps a complete redesign.


Perhaps we could do both in parallel? -

 * Start work now on a TLS 1.3 that is a cleaned-up / stripped-down
profile of TLS 1.2, without major handshake changes or new features,
aiming to finish in a few months.

 * Place a call for proposals for TLS 2.0, with the intent of choosing
one as a WG item within 4-6 months.

---

I hear the concern that people don't want a "clean-slate" or
"revolutionary" redesign of TLS, they just want to quickly make the
"minimal" changes to 5246 that meet our charter.

I'd encourage such people to re-read the charter, and look at Eric's
1.3 draft.  The goals and designs being considered are *already* a
radical break from your parent's TLS.  We'll have complex, difficult
debates involving competing visions for TLS regardless of what process
we choose.

Having different proposals is not going to create this problem.  But
it will help us navigate it, by making it easier to compare the
implications of inter-related design decisions.

Here's an example of the questions we have to resolve, and which I
think will be hard to handle with individual consensus calls if we
don't have a holistic picture of what we're choosing:


(1) Can pre-delivered public keys (via DNS? html? other?) be used to
encrypt the handshake or even app data (e.g. Andy Lutomirski's
"handshake keys" for protecting SNI, or "semi-static public keys" for
0-RTT initial connections)?

(2) Should 0-RTT reconnection be achieved via a traditional
session-ticket flow, or through a new flow based on caching a
semi-static public key?

(3) For either sort of zero-RTT reconnection, how do we design an
"anti-replay" capability which is practical and scaleable, and doesn't
leak tracking info?

(4) For zero-RTT cases, should we overlay an additional DH exchange on
the 1st RT to increase forward secrecy for subsequent data?  Or should
this be accomplished by a more general re-handshake capability?

(5) Assuming we go with the zero-RTT semi-static key approach for
reconnection, should we also re-implement the initial handshake in
terms of it (i.e. spend the 1st RT to retrieve the semi-static key),
which makes things simpler but otherwise is less optimal than
retrieving a fresh ephemeral?

(6) Should we stick with a signed-DH key agreement, or consider
alternatives (e.g. SKEME, MQV, NTor, TripleDH, other?).

(7) Should client auth be integrated into the handshake or moved to a
post-handshake, channel-bound layer?

(8) Should the protocol be integrated (somehow) with TCP or a TCP
replacement (e.g. QUIC, MinimaLT, TCPcrypt)?

(9) What should be done to minimize tracking / info-leaks in the
protocol (e.g. remove / randomize session tickets / SessionIDs, remove
other options, Elligator-type indistinguishability, more padding)?

(10) Stylistic decisions:
 - choice of ciphersuites?
 - preserve TLS message formats or replace them?
 - larger extension spaces? (end the 16-bit suffering!)

etc....

Trevor