Re: [TLS] Proposed text for removing renegotiation

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu, 2014-06-19 at 08:28 -0700, Martin Thomson wrote:
> On 19 June 2014 03:26, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> > My counter-proposal would be:
> > 1. Removing the Note "If a rehandshake occurs while data is flowing on a
> > connection, the communicating parties may continue to send data using
> > the old CipherSpec."
> >
> > 2. Adding the text: "During the handshake process implementations SHALL
> > NOT allow application protocol data exchange. Implementations SHALL
> > terminate the session if application protocol data is received." (in
> > DTLS that data may arrive due to network errors so they should be
> > quietly discarded.
> >
> > 3. Adding the text "Since the authentication credentials may change
> > during a renegotiation the upper layers must be notified of either the
> > new negotiation process or any identity change."
> >
> > That would make renegotiation a strictly inband process, and
> > applications would be able to distinguish traffic before and after a new
> > negotiation.
> 
> That sounds strictly worse than what we have today.
> 
> Points 1&2 render the connection unusable, something that many
> applications can't have.

Could you elaborate on the applications that will be affected by such
change? I've never seen any such applications, and in fact for the 99%
of the renegotiation uses (e.g., the web) the renegotiation operation
would be identical before and after my proposed change. The only
applications that could potentially interleave TLS application and
handshake data are TLS-based VPNs, and there aren't any that do that
(and they could if they are required to, that's why there is a SHALL NOT
there instead of must).

The other advantage is the symmetricity of TLS handshake and
re-handshake. By allowing application data during the re-handshake one
opens the door for allowing application data during the handshake, if an
implementer doesn't distinguish the two perfectly symmetric options.

>   In many respects - other than TCP congestion
> window warmup perhaps - this is equivalent to Brian's proposal to
> remove renegotiation and replace it with nothing, forcing people to
> make new connections.

I disagree with this evaluation, as there is no data to back that up.

regards,
Nikos