Re: [TLS] Proposed text for removing renegotiation

[Nikos Mavrogiannopoulos <[e-mail]>]

On Wed, 2014-06-11 at 08:45 -0300, Watson Ladd wrote:
> >> Quick: what is the proper response when the Certificate changes
> >> between a negotiation and a renegotiation?
> >
> > That is on the application protocol to decide.
> Always the wrong answer: we know more then the application layer
> people do about security, just as the networking people know more than
> we do about sending packets through the network.

Sorry, but I don't believe you understand the issue. Authentication is
to the application layer to decide. The secure transport protocol cannot
know or guess when and if authentication is desired by the upper
protocols. TLS should determine the algorithms and the methods, but the
upper protocols should set the timing and the allowed combinations. It
may be very legitimate to switch my user-certificate to access a
different web page; that cannot be mandated by TLS.

> >> What is the relation between the two connections? Can there ever be
> >> sensible semantics for this?
> >> Renegotiation makes reads block on writes, a problem for all
> >> event-based systems. Exposing renegotiation to application level code
> >> is hard.
> > It has been done already, and not only once. Could you provide evidence
> > of this hardness that you claim?
> Where has this been done?

I'd suggest you to check existing TLS implementations, or read the
discussion in the triple handshake paper (section II).

> As for the hardness, most applications expect a stream of bytes.
> Renegotation is OOB data.

What is the issue with that?

> >> Show me a formalization of renegotiation semantics, and I might be
> >> convinced otherwise.
> > I think it is up to the one proposing the change to provide evidence of
> > the contrary and there has been none so far. Otherwise we do things like
> > prove me TLS secure  combination or we drop it completely. Formal models
> > lag behind protocols.
> You guessed what the next email from me when EKR posted his draft was
> going to say. Since miTLS finished up this has been a reasonable
> position: TLS 1.2 has fairly well understood security, so TLS 1.3
> should be better, not worse. Or do you think that three attacks in
> three years is acceptable?

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?

> Where is the usecase that needs renegotiation in TLS 1.3? I've not
> seen it: we've provided alternatives for all of them.

I don't buy the we have provided alternatives for all of them, because
you fail to show the issue that is so grave that requires throwing out
renegotiation, and re-inventing it.

>  Why do you care
> what we do to provide an easy protocol to analyze? If there is a case
> for keeping renegotation, make it:

Sorry, protocol design doesn't work like that. If you want to change or
remove something, you need to make a case for that, and it is up to you
to make solid arguments. Making a change an basing it on arguments like,
(1) everyone knows that, (2) this paper supports my opinion -but it
doesn't-, doesn't give any credibility to your proposal.

Maybe you are right, but unless you make your case with solid arguments,
you haven't convinced me.

> >> But to say that it is
> >> "not complex" belies the experience of implementors, theorists, and
> >> the past 17 years of security
> > It's good to know that you are representing them. Could you share your
> > experience with implementing or modeling TLS? Or at least cite some
> > document that backs up the claims that you make.
> Let's see: there's the discussion in the Triple Handshake paper of how
> applications respond to these changes,

Which changes do you refer to, and which discussion. The paper as I read
it, makes no claims that renegotiation is overly complex or cannot be
modeled. On the contrary, it is mentioned that it is already modeled in
mitls.

>  the previous renegotiation bug,

It was addressed long time ago.

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

regards,
Nikos