Re: [TLS] Proposed text for removing renegotiation

[Watson Ladd <[e-mail]>]

On May 27, 2014 5:44 PM, "Martin Rex" <[e-mail]> wrote:
>
> 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.

The security considerations never mentioned the issue.  In fact you were
one of the codiscoverers, years after the spec was authored. Do you
consider it a nonissue?

One can argue that TLS never has flaws, just assumptions that it is
"secure" which aren't true. Or one could say that we have to provide
semantics people expect.

>
>
> 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?

Does resuming the same connection twice make sense? Now that you mention
the issue I see how it can happen. But we only need to refresh the keys
used for data, not the PMS.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls