Re: [TLS] tls 1.3: renegotiation

[Robert Ransom <[e-mail]>]

On 7/28/14, Martin Thomson <[e-mail]> wrote:
> On 25 July 2014 12:27, Robert Ransom <[e-mail]> wrote:
>> In addition, I believe that it is not possible for the WG to make an
>> informed decision as to whether renegotiation should be removed at
>> this time:
>>
>> * The rekeying feature and client-initiated client authentication
>>   feature have not been specified yet, even to the point of stating
>>   the requirements which each feature will meet.  It is not possible
>>   for the WG to determine whether the features intended to replace
>>   these two uses of renegotiation will be fit for their intended
>>   purposes at this time.
>
> We had a good discussion about these in Toronto.  On rekeying, there
> are concerns about how much we might want to make changeable; offline
> discussions about the complexity/value trade-off space between simple
> rekeying (as I have proposed) and something more complete like a full
> DH exchange was quite enlightening.

I see.  So you don't even have a consensus on what “rekeying” will mean.


> We've talked quite a bit about spontaneous client authentication
> (though we might talk about client-initiated authentication, that
> implies a solution and so I think that is the wrong focus for the
> discussion).
>
> The problem as always is that the defense of renegotiation is largely
> based on its existence alone.  That defense would be stronger if there
> it were based on use cases.  I don't find arguments from inertia ("it
> exists", or "it's easy") to be at all persuasive.  Saying "it can be
> fixed" is actively detrimental to the case.
>
> Arguments in the form "I need to do X and in order to do X I need
> renegotiation" are far better.  They are testable.  Andrei's concerns
> are a good example of this.  We might disagree on the subjective
> elements, but that's a good starting point.

I gave a list of four use cases that can be (and are currently)
addressed by renegotiation a while back.  The responses can be summed
up as “But we can add a separate ad-hoc feature to address each of
those use cases!”.  I agree that each use of renegotiation can be
replaced with a new protocol feature, which will require new protocol
design effort, new implementation code, new testing, new API design
effort, new application code, and new risk of introducing security
bugs at each of those steps.  I do not agree with your argument that
such a replacement is desirable for every use of renegotiation -- or
for *any* use of renegotiation at all.

Renegotiation is a particularly elegant solution to several problems.
It requires little extra code beyond what is already used to perform
the initial handshake, and adding a (correctly designed) channel
binding as input to the renegotiation process will add the security
properties that some API and application developers had previously
expected renegotiation to provide.

I don't find arguments based on the prospect that new features might
be added to TLS to be at all persuasive.  Saying
“TLS-without-renegotiation can be fixed to support long-lived
connections if we decide to add some sort of rekeying mechanism.” or
“We added a Heartbeat record type; now let's add a ClientAuthenticate
record type too!” are actively detrimental to the case.


Robert Ransom