Subject: [TLS] TLS process thread

From: Sean Turner <[email-masked]>
Date: Wed, 9 Apr 2014 16:49:47 -0400

All,

Thanks for your comments on the TLS 1.3 process.

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.

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. The chairs do not believe
there is a convincing reason or support to deviate from the plan
described in our previous message [1]. Complaints about this
process should be addressed to our Area Director, Stephen Farrell.

As mentioned in the chairs previous message, we are first addressing
the handshake flows, and specifically the cryptographic skeleton for
the handshake.  We will be holding an interim meeting devoted directly
to this topic; expect a message proposing dates for that shortly.

Sean Turner for the chairs

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 10 Apr 2014 10:14:00 +0200

> to a final selection and instead get bogged down in the selection

Hello,
 That was not an issue with the selection of SSL 3.0, the document that
was the basis of this working group.

> document.

I am sorry, but I disagree. The charter proposed in [0], does not even
mention RFC5246, and its points cannot possibly minimize the changes to
RFC5246. It proposes the creation of a new protocol. For example:

o Develop a mode that encrypts as much of the handshake as
is possible to reduce the amount of observable data to
both passive and active attackers.

o Develop modes to reduce handshake latency, which primarily
support HTTP-based applications, aiming for one roundtrip
for a full handshake and one or zero roundtrip for repeated
handshakes.   The aim is also to maintain current security 
features.

If these two are addressed in TLS 1.3, it will be a new protocol whether
or not it was based on RFC5246. Even worse it will be a new
cryptographic protocol designed in a working group that explicitly says
it is not a working group of cryptographers.

[0]. http://datatracker.ietf.org/doc/charter-ietf-tls/

regards,
Nikos

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Apr 2014 07:07:37 -0700

> to a final selection and instead get bogged down in the selection

This conflates two different things that people asked for: having people create full proposals and picking among them, and designing TLS from security and transport principles unfettered by the current handshake and message format. I have had plenty of experience with the first in the IETF, and I agree that it rarely goes well. However, there is good reason to look at the second.

> namely RFC 5246, and a mandate to minimize the changes to that

No, it doesn't say either of those. The actual quote, which the WG worked hard on, is "With these objectives in mind, the TLS WG will also place a priority in minimizing gratuitous changes to TLS."

> This does not mean that ideas for significant changes are

Instead of formulating it as a "complaint", it would be more helpful to formulate it as a question. Stephen: do you support the chairs' interpretation that the charter prevents the WG from designing TLS from security and transport principles unfettered by the current handshake and message format?

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Apr 2014 15:26:18 +0100

Hi Paul,

On 04/10/2014 03:07 PM, Paul Hoffman 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.
> 
> This conflates two different things that people asked for: having
> people create full proposals and picking among them, and designing
> TLS from security and transport principles unfettered by the current
> handshake and message format. I have had plenty of experience with
> the first in the IETF, and I agree that it rarely goes well. 

I fully agree with you and the chairs on that.

> However,
> there is good reason to look at the second.
> 
>> In this case, however, our charter provides a clear starting
>> point, namely RFC 5246, and a mandate to minimize the changes to
>> that document.
> 
> No, it doesn't say either of those. The actual quote, which the WG
> worked hard on, is "With these objectives in mind, the TLS WG will
> also place a priority in minimizing gratuitous changes to TLS."
> 
>> 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. The chairs do not believe there is
>> a convincing reason or support to deviate from the plan described
>> in our previous message [1]. Complaints about this process should
>> be addressed to our Area Director, Stephen Farrell.
> 
> Instead of formulating it as a "complaint", it would be more helpful
> to formulate it as a question. Stephen: do you support the chairs'
> interpretation that the charter prevents the WG from designing TLS
> from security and transport principles unfettered by the current
> handshake and message format?

Nicely constructed question:-) Short answer: Yes I support the
chairs, but I don't think the question you asked is that useful,
nor can it be at this level of abstraction, until the WG have
reached consensus on more of the features of TLS1.3.

Put another way, I think what the chairs have said is fine, but
does not "prevent the WG from designing TLS from security and
transport principles" that deviate from "the current handshake and
message format."  (I did s/unfettered by/that deviate from/ there
as I don't think unfettered is a useful term here - who'd want to
be fettered?;-)

Of course the WG might come to consensus that large (non-gratuitous)
changes are needed and I don't think the chairs are saying such
would not be allowed. However, I also assume that implementers are
interested in less, rather than more, change, so starting
from 5246 seems entirely reasonable to me. I do not think the
chairs are saying that TLS1.3 has to look almost the same as
5246 though - the delta will depend on how discussions go about
which features to add/keep/change/drop. And I also don't believe
that the chairs have ruled out deciding at some point that
the delta has gotten so big that re-organising the text entirely,
or re-starting from a blank sheet might be right. (Though I'd
be surprised if that last made sense to be honest.)

I do think that there is a benefit for implementers if the
TLS1.3 RFC ends up having a simpler delta from 5246 but at the
same time we are discussing some possibly significant changes.
Its up to the WG to figure those out and the chairs to manage
that process and judge the consensus. I think what the chairs
are saying (and they'll correct me if I'm wrong) is that for
each proposed change they'd like that change discussed as a
delta from 5246, and they have set out a rough ordering of
when to discuss which TLS1.3 features and on that basis
starting editing from 5246 text at some point seems just
sensible to me.

And to give a concrete but deliberately not realistic example,
(to try avoid ratholing on it) I do think it'd be ok for someone
to propose replacing the TLS specific encoding of structured
data with XML if they cast that proposal in terms of a delta
from 5246, and if the WG had consensus on that then that'd be
in line with what the chairs have proposed. But I guess that
there'd be a pretty high bar to get over there in terms of
convincing implementers that such a change would be a good
plan even if you replaced XML with something that someone
might suggest.

Hope that helps,
S.

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 15 Apr 2014 00:55:24 -0700

> to a final selection and instead get bogged down in the selection

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.

> 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
> 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

---

From: Douglas Stebila <[email-masked]>
Date: Tue, 15 Apr 2014 08:06:26 +0000

> expressed interest in soliciting multiple proposals [10,11,12,13].

+1

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 15 Apr 2014 14:48:33 +0200

> more sense to explore such a complex design space through different

To me, it seems a critical question is whether a handshake initiated
by a (D)TLS vNext client to an existing (D)TLS 1.x server is expected
to succeed (without extra round trips, etc.) or not.

If yes, then vNext = 1.3 and there's only so much that can actually be
changed without breaking backwards compatibility. For example (if I
understand it correctly), removing compression basically means that
compression must not be negotiated, not that the
ClientHello.compression_methods field can be removed. Any significant
changes will need to jump through some hoops to remain backwards
compatible, like for example the encapsulation of TLS records in
ClientHello extensions (ugh). I wouldn't be surprised if most things
that can be done could even be done if vNext = 1.2bis.

If no, then vNext = 2.0 really and there's no reason why it shouldn't
be a clean reinvention of Internet transport layer security that
doesn't have to look like TLS 1.2 but nevertheless stands on the
shoulders of the 15+ years of SSL/TLS 1.x experience.

Klaus

---

From: Paul Lambert <[email-masked]>
Date: Tue, 15 Apr 2014 19:15:50 -0700

+1

Multiple proposals would be valuable.  It would also be
important to have proposals briefly describe unique use cases
and requirements.  

There seem to be some conflicting use cases that
need clarification as part of the process.

Paul

> 
>
>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls