Re: [TLS] TLS process thread

[Stephen Farrell <[e-mail]>]

Hi Paul,

On 04/10/2014 03:07 PM, Paul Hoffman wrote:
> On Apr 9, 2014, at 1:49 PM, Sean Turner <[e-mail]> wrote:
> 
>> 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.
> 
> 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.




> 
> --Paul Hoffman
>