Re: [TLS] TLS chairing changes

[Trevor Perrin <[e-mail]>]

On Wed, Mar 12, 2014 at 8:43 AM, Stephen Farrell
<[e-mail]>wrote:

>
> Hi Trevor,
>
> On 03/12/2014 03:06 PM, Trevor Perrin wrote:
> > On Tue, Mar 11, 2014 at 3:54 PM, Stephen Farrell
> > <[e-mail]>wrote:
> >
> >>
> >> Effective April 1st, Sean Turner will become a third TLS
> >> co-chair in order to free up Eric who will be a TLS 1.3
> >> document editor.
> >
> >
> >
> > Hi Stephen,
> >
> > There was discussion about having a more competitive process for TLS 1.3
> > [1].
>
> I'm not at all sure a "competition" is the right way to pick
> an initial draft as a starting point. Of course, people are
> free to write any I-D they choose and propose that to the WG,
> but I think that the process being followed so far of discussing
> the features and building from those seems to be going fine.
>

I thought EKR's drafts were more of a brainstorming / strawman to get
people thinking about things [1,2].

I assumed at some point after re-chartering we'd discuss process,
timelines, and requirements some more, and have an open process for TLS 1.3
candidates.  Until your email, it wasn't made clear - at least to the list
- that EKR's draft was the presumptive TLS 1.3.

It's great that EKR's draft is driving discussion.  But that draft makes
many choices which may be optimal, or may not:

 * For an initial handshake, EKR's draft recommends a 2-RTT flow with 2 DH
computations.  I think it could also support a flow with 1-RTT, 2 DH, and
reduced foward secrecy for the first RT of Application Data.  This seems a
step backwards from current TLS, which can support a False-Start handshake
with 1-RTT, 1 DH, and full forward secrecy.

 * For a "reconnect" handshake, EKR's draft performs DH with a
"semi-static" DH key.  This is more computation than a traditional
session-ticket resumption.

 * EKR's draft assumes we want to reuse TLS structures as much as possible,
for simplicity.  An alternative would be to design structures which are
more different from TLS, but more simple in their own right.

And there's a lot else to be decided wrt key agreement, ciphersuites,
renegotiation, SNI, potential integration with (Client Auth, ChannelID,
PAKE, TACK), etc.

Anyways, I'd prefer a process where the WG held off from anointing a single
draft as "the" TLS 1.3 WG item for several months, and invited individual
contributions.  Eric's draft would be such a contribution, but so could
designs based on QUIC or MinimaLT, or anything else.

This would let us to explore the design space via comparing and contrasting
different designs.  Once the WG was satisfied that it preferred one
candidate, this would be made a WG item for finishing the spec.


Trevor


[1] http://www.ietf.org/mail-archive/web/tls/current/msg10404.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg11300.html