Re: [TLS] Proposed text for removing renegotiation

> And the main point, which is that it's not the lack of a
> notification API for renegotiation that causes the issue,
> it's the fact that it can happen at all.

If there is not general agreement on what "the issue" is, there won't be agreement on how to solve it.  If "the issue" is "we don't like renegotiation", then of course no solution other than eliminating renegotiation will solve it.

But if the issue is that applications on each side of a TLS connection don't have a common understanding of what parameters have been negotiated and when they become effective, then an API that supports data semantics identical to "Close and Open TCP" without actually negotiating a new TCP connection is a valid solution.

An application must be guaranteed that all data sent or received prior to renegotiation uses the old set of parameters and all data sent or received after uses the new set.  The TLS library should arrange for that to happen such that the data flowing in one direction (written on the initiating side) flows continuously over the wire, slowed only by the TLS handshake bytes transmitted in that direction.  Data in the other direction is delayed as necessary to sync with the transition.

Note 2 may be overly restrictive if "handshake process" is interpreted to include any round trips.  It should include only messages that trigger the use of new parameters; there is no reason to block data while sending setup messages that have not yet taken effect.

>> That would make renegotiation a strictly inband process, and 
>> applications would be able to distinguish traffic before and after a 
>> new negotiation  ---> becomes effective <---.

That is the requirement.

Dave

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Thursday, June 19, 2014 11:28 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation

On 19 June 2014 03:26, Nikos Mavrogiannopoulos <nmav@redhat.com> 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.  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.

And the main point, which is that it's not the lack of a notification API for renegotiation that causes the issue, it's the fact that it can happen at all.

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