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

Over the past week, I've been watching for an answer to the question posed regarding how we deal with the situation where the server must examine some Application Data messages in order to determine whether client authentication is required.

Presently, this situation is handled by allowing an unauthenticated client to send some Application Data, then if client authentication is required, it will send a HelloRequest, starting renegotiation. During the subsequent handshake, the server sends a CertificateRequest and drops the connection if the client fails to authenticate and authorize.

I've seen the following concerns raised with this approach:

1) How does the client authentication persist (or not persist) in the face of session resumption?

2) If the answer to #1 is that yes, the authentication persists, then does the most-recently-supplied identity replace or aggregate with previous identities presented in the same session?

I worked through a number of possible alternatives where we separate client authentication completely from the handshake, and I think the solution lies down this path; however, before digging into those details, let me ask for the group's consensus on the two questions posed above.

I would argue that session resumption should revert the client's identity back to "unauthenticated". This avoids a lot of the complicated workarounds required for #2.

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Thursday, June 26, 2014 7:31 AM
To: Joseph Salowey (jsalowey)
Cc: <tls@ietf.org>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation

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.

-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls