Re: [TLS] TLS 1.3 process

[Trevor Perrin <[e-mail]>]

On Fri, Mar 28, 2014 at 8:34 AM, Eric Rescorla <[e-mail]> wrote:
>
> On Fri, Mar 28, 2014 at 7:40 AM, Nikos Mavrogiannopoulos <[e-mail]>
> wrote:
>>
>> On Fri, 2014-03-28 at 10:12 -0400, Salz, Rich wrote:
>> > > The TLS WG charter is pretty clear that the intention isn't to design
>> > > a completely new protocol but rather to revise TLS,
>> > > and specifically to "place a priority in minimizing gratuitous changes
>> > > to TLS."
>> > +1.
>> >
>> > It seems to me that there are almost three viewpoints within this WG.
>> > With the hope that I'm equally unfair to everyone, I'd summarize them like
>> > this:
>> >       - Update to modern crypto knowledge to fix bugs, and some modern
>> > features and be done
>> >       - Make big changes to fix serious problems
>> >       - Start over from a clean sheet; "I don't know what it will be,
>> > but we'll call it TLS."
...
>> This is not my impression of the discussions and the meetings. Eric in
>> the last meetings has presented a list of changes to the protocol that
>> really exceeds the "Update to modern crypto knowledge to fix bugs, and
>> some modern features and be done", (whatever that means).
>>
>> So my understanding is that there will be big changes (e.g., reducing
>> handshake messages, redesign of handshake to encrypt everything) to fix
>> serious and not serious problems (e.g., reducing the round-trips),
>
>
> Yes, I think the changes to the handshake we have been discussing
> probably would fall under #2 in Rich's taxonomy.

Agreed with Nikos and Eric that the WG (and charter) seemed willing to
consider major changes, as evidenced by the interest in Eric's "new
flows" draft.

If anything, I'm not sure the difference between Rich's #2 and #3
really exists - if we're willing to replace the existing TLS initial
and resumption flows with a flexible composition of exchanges based
around semi-static public keys, zero-RTT pre-emptive encryption, and
anti-replay tokens (Eric's draft) - and revisit the crypto - then
we're designing a new protocol, whether we admit it or not.


>> and
>> the question is whether to do it:
>> 1. within the working group (which is stated to have no crypto
>> expertise).
>> 2. by using external expertise.
>
>
> I actually don't think think this is the question, since IETF work is
> done in WGs and we would reach out (and are reaching out) for
> external expertise in any case.

Don't fully agree with Nikos.  For (1), this WG *does* have
participation from many cryptographers.  For (2), it's true anyone can
participate.

But Nikos has a point - there are differences in how processes
encourage or discourage participation.

I think creating a complex protocol by trying to reach consensus on a
hundred different points individually will result in a huge volume of
complicated, hard-to-follow discussions, which will need to be sorted
out at f2f meetings with substantial wrangling and steering from the
chairs.

So the only people able to fully participate will be those willing to
invest hours a day deciphering mailing list threads and trying to
"win" discussions, and spend the time and money to attend IETF
meetings where the big decisions will be made.

In contrast, a process based around alternative proposals makes it
much easier to participate by either submitting a proposal or
reviewing others.  And the range of things being considered becomes
much more legible, since once can review a few leading proposals
instead of trying to reverse-engineer debates embedded in thousands of
mailing list posts.


Trevor