Re: [TLS] Bakeoffs

[Mark Nottingham <[e-mail]>]

I strongly agree with the notion that bakeoffs are, at best, inadvisable. 

The IETF isn't set up to do this sort of thing; the best way to get traction here is to get implementation experience / buy-in.

Working on TLS 2 at the same time as TLS 1.3 is in active development is asking for both to fail, IMO.

Regards,



On 17 Apr 2014, at 9:21 am, Trevor Perrin <[e-mail]> wrote:

> 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
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   http://www.mnot.net/