Re: [TLS] Call for Consensus on removal of renegotiation

[Andy Lutomirski <[e-mail]>]

On 06/26/2014 06:23 PM, Watson Ladd wrote:
> On Thu, Jun 26, 2014 at 7:30 AM, Martin Rex <[e-mail]> wrote:
>> Joseph Salowey (jsalowey) wrote:
>>>
>>> 1.  In favor of removing renegotiation
>>> 2.  In favor of removing renegotiation with the addition of rekey facility
>>> 3.  Not in favor of removing renegotiation
>>
>>
>> (3) Leave it in the spec,  Make it a true option for implementors.
>>     with a guidance that clients might need it for interop, but should
>>     play safe (and nail down identities once they're established) by default
>>
>>
>> I never offered/exposed renegotiation at the API to application callers,
>> and since January 2010, I have the server-side reject renegotiation attempts
>> from clients.  But the installed base of _other_ servers that use
>> (or require) it is to large to be ignored, and I don't see it go away
>> that easily...
>>
>> Everything that you change from TLSv1.0/1/2 toward v1.3 will add complexity
>> and require more code.  This applies not just to adding new features, but
>> also to axing existing features that may be in current use.
>>
>> A TLSv1.3 spec that requires implementors to carefully avoid TLSv1.3 for
>> a number of commonly used TLSv1.0/1/2 features may be even harder to
>> sell than TLSv1.2 and IPv6.
> 
> I think this is an excellent point: unless we are making TLS 1.3 web
> only, and committing to supporting TLS 1.2 (including renegotation!)
> for
> a long time, we cannot ax this feature. As much as I dislike
> renegotiation, it may be that we need to include it as an optional
> feature if we want to replace TLS 1.2.

Are there any known non-HTTP users of renegotiation for client auth that
wouldn't work out of the box with unsolicited client auth during the
handshake?

The only compelling objection to removing renegotiation for client auth
that I heard was that it would be unfortunate for TLS 1.3 to only be
usable with an upgraded HTTP stack.  That's not a show-stopper, but it's
annoying.

Allowing delayed client authentication without a new handshake would
solve this problem, is cryptographically very simple*, but integrating
it into the protocol might be quite complicated.

* It would preclude using tricks like triple DH directly, though.

--Andy