Re: [TLS] Proposed text for removing renegotiation

[[e-mail] (Martin Rex)]

Martin Thomson wrote:
> 
> Here I'm proposing changes that remove renegotiation.
>
> It's not possible to just remove renegotiation.
> After removing HelloRequest and no_renegotiation, there are some
> things that need to be fixed.  The current and pending states for
> both read and write direction are integral parts of the spec.

I haven't looked at the details, but this sound terrible.

The beauty of the original TLS renegotiation is that it doesn't
really exist.  For the state machine, it is a regular full TLS
handshake, for the record layer, it is just a replacement of
the current state with the next state upon CCS.

The only problem with TLS renogitation, if there ever was one,
is with the flawed assumptions of the application about what
characteristics it provides (i.e that another successful TLS
handshake could be abused to provide an OTP-style authentication
of all data previously received over that TLS channel.


Renegotiation could be combined with an abbreviated TLS handshake
to provide fast rekeying of the traffic protection keys (not creating
a new entry in the TLS session cache), and renegotiation could be
combined with a full TLS handshake, creating a new, self-contained
entry in the TLS session cache that can be resumed on different
connections with an abbreviated TLS handshake.


Conceptually, the TLS session cache is readonly after an entry
is created, and that is GOOD, i.e. full TLS handshakes create new,
distict session cache entries, and abbreviated TLS handshakes resume
existing session cache entries and *NEVER* modify them.


The original architecture allows for a very simple and robust
TLS protocol state machine for the TLS handshake (allows!=implies,
you can implement arbitrarily complicated TLS state machines if you
so desire, just look at some of the OpenSource implementations).



> 
> The proposal generates a new master secret from the previous using the
> same formula that is used to generate the master from the pre-master
> secret.  Obviously, if we change that formula (and it seems likely
> that we will) then this should be changed too.

It sounds like quite a lot more stuff will have to be carried over
from the previous session state to the next.  Now what does this mean
for the abbreviated TLS handshake?  When, where and how do you issue
a new session ID, or how does this change affect abbreviated
TLS handshakes happening on independent parallel connections? 


-Martin