Re: [TLS] Proposed text for removing renegotiation

[Nikos Mavrogiannopoulos <[e-mail]>]

On Fri, 2014-06-13 at 08:34 -0300, Watson Ladd wrote:

> The issue is the following: most applications do something like this
> parse_request(conn)
> check_if_request_authorized(conn)
> 
> This assumes that the authentication state doesn't change in between
> the two lines, or midway through the parse.
> With renegotiation it can.

Indeed, but this is an easily unsolvable issue. That can be easily
avoided on the implementation side (and gnutls is does not allow that).
I have numerous times asked to clarify and better specify this part on
the past.

> Furthermore, renegotiation makes writes block on reads. That can cause
> pain for event based systems.

I don't understand what do you make by makes writes block on reads.
Renegotiation is the same a negotiation in TLS. The same issues that
exist in the TLS handshake will exist in the rehandshake. Nevertheless,
I've used many even-based systems with TLS with no issue.

> > I don't think anyone would disagree with what you say here. But you are
> > avoiding to reply to the point. Was the new proposal you endorse proven
> > secure, or do we replace the old method, -that you claim is insecure-
> > with yet another method that will be proven insecure in few years?
> What new proposal have I endorsed?

The whole thread is about dropping renegotiation _and_ replacing with a
mechanism proposed by Martin Thompson.

>  No, you do the work to show your
> protocol is secure.
> Up until now, we haven't, and users have paid the price.
[...]
> >> virtually every paper on the TLS handshake until miTLS, etc. Can you
> >> point to someone providing an adequate explanation of what
> >> renegotation does?
> > This is not a citation, you could replace it with "everyone knows that".
> > If you really have a point, because it is not of your own experience,
> > please cite it properly.
> Go to eprint.iacr.org. Search TLS:
> http://eprint.iacr.org/2013/339.pdf "we do not model renegotation/resumption"
> http://eprint.iacr.org/2012/630.pdf Analyzes the renegotation fix, a
> full 3 years after the fix was proposed and adopted, and TLS does not
> meet strongest security model.
> http://eprint.iacr.org/2014/020.pdf Renegotation isn't mentioned.
> I did skip over a few papers but the message is clear: renegotiation
> is not currently amenable to analysis.

Interesting observation. However, the fact that renegotiation has not
been modeled in some papers doesn't reveal much except that the formal
protocol verification lags behind protocol design. If you check the
papers that you reference you'll notice that it is not only
renegotiation that they don't model. The first one doesn't even model
ciphersuite negotiation which is the basis of the protocol. The second
does mention that renegotiation can be modified to avoid a stronger
adversary, i.e., an adversary that can learn the previous session keys.
That's an interesting paper, but whether we really need to protect
against this adversary is really up to discussion.

Most often in academic papers (with the exception of mitls work) they
simply model a single ciphersuite and prove it secure; then in the next
month you see an new attack on the same ciphersuite that was proven
secure, because the majority of the protocol interactions were ignored.
That does not show that we need to drop all the protocol options and
only allow for RSA-AES-CBC for example (which was proven secure numerous
times prior it was broken). If we had followed that path and dropped
ciphersuite negotiation, renegotiation, and session resumption, only to
allow the "proven" secure options, now TLS would be broken and we
wouldn't have a way to fix it.

regards,
Nikos