Re: [TLS] TLS process thread

[Trevor Perrin <[e-mail]>]

On Wed, Apr 9, 2014 at 1:49 PM, Sean Turner <[e-mail]> wrote:
>
> While the IETF certainly has used competitions in the past, they are
> generally used to select one document from multiple starting points
> and then the documents undergo substantial revisions. Even then, there
> is a fairly mixed track record as WGs often find it very hard to come
> to a final selection and instead get bogged down in the selection
> process.

Hi Sean,

Have there really been enough IETF crypto-protocol competitions to
draw this conclusion?  Could you give examples?

IKEv1 was mentioned by Stephen Farrell [1].  But Dan Harkins and Peter
Gutmann argued its problems were less due to the ISAKMP/SKIP
competition, and more due to what happened afterwards - "option being
piled on top of option" creating a "design-by-committee mess" [2,3].

As for getting "bogged down in the selection process" -  having so
many strong candidates it's hard to choose sounds like a good problem
to have.  If the designs are similar, we'll have more confidence in
them.  If they're different, we'll have context to argue the
trade-offs.


> In this case, however, our charter provides a clear starting point,
> namely RFC 5246, and a mandate to minimize the changes to that
> document.  This does not mean that ideas for significant changes are
> are not welcome, but they should be phrased as revisions to RFC 5246
> rather than as a wholesale replacement.

As Nikos and Paul pointed out, the charter doesn't mention 5246.  It
mentions minimizing changes, but only as one goal among several, and
only "gratuitous" changes.

I think minimizing changes is one of many goals in tension with others
(minimizing diffs vs minimizing complexity / adding features;
handshake encryption vs handshake latency; new features vs. ease of
analysis; merging layers vs. modularity; etc.)  Instead of presuming
the answer to any of these, or tackling them in isolation, it makes
more sense to explore such a complex design space through different
proposals.


> The chairs do not believe
> there is a convincing reason or support to deviate from the plan
> described in our previous message [1].

Reviewing the "TLS 1.3 process" threads [4,5], I see more support for
alternatives:

 * Adam Langley suggested a "TLS 1.3 that is a tidying up of 1.2 [...]
The more significant changes could be 1.4" [6].  Peter Gutmann
endorsed this, and Watson Ladd and Rich Salz seemed somewhat
interested in such an approach [7,8,9], as am I.

 * Nikos, myself, Peter Gutmann, Watson, and Daniel Kahn Gillmor
expressed interest in soliciting multiple proposals [10,11,12,13].

 * Bill Frantz suggested having a set of "use cases to test our
proposals against" [14].  Support was expressed by Watson, Peter
Gutmann, and Andy Lutomirski [15,16,17].

It also seems these discussions were cut short by extended_random and
heartbleed revelations.

I don't know whether the WG has consensus for any of the above, but
it's not clear there's consensus for your process either.

Perhaps the chairs could try to clarify the main alternatives and put
it to the WG for a decision?


Trevor

[1] http://www.ietf.org/mail-archive/web/tls/current/msg11679.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg11701.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg11709.html
[4] http://www.ietf.org/mail-archive/web/tls/current/msg11657.html
[5] http://www.ietf.org/mail-archive/web/tls/current/msg11655.html
[6] http://www.ietf.org/mail-archive/web/tls/current/msg11691.html
[7] http://www.ietf.org/mail-archive/web/tls/current/msg11711.html
[8] http://www.ietf.org/mail-archive/web/tls/current/msg11694.html
[9] http://www.ietf.org/mail-archive/web/tls/current/msg11685.html
[10] http://www.ietf.org/mail-archive/web/tls/current/msg11677.html
[11] http://www.ietf.org/mail-archive/web/tls/current/msg11670.html
[12] http://www.ietf.org/mail-archive/web/tls/current/msg11655.html
[13] http://www.ietf.org/mail-archive/web/tls/current/msg11656.html
[14] http://www.ietf.org/mail-archive/web/tls/current/msg11717.html
[15] http://www.ietf.org/mail-archive/web/tls/current/msg11723.html
[16] http://www.ietf.org/mail-archive/web/tls/current/msg11720.html
[17] http://www.ietf.org/mail-archive/web/tls/current/msg11792.html