Re: [TLS] Proposed text for removing renegotiation

[Watson Ladd <[e-mail]>]

On Fri, Jun 13, 2014 at 5:42 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> 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.

Sure, but then we should make clear that the upper-level protocol
should control when renegotiation happens.

Right now it's a free-for-all: you can change the authentication state
repeatedly in the course of reading a request.
As a result, when the application checks what the authentication state
is there is a TOCTOU problem.

The renegotiation fix kind of solves this problem: it takes data from
the first connection and links it to the second.
>
>> >> 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?

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.

Furthermore, renegotiation makes writes block on reads. That can cause
pain for event based systems.
>
>> >> 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?

What new proposal have I endorsed? No, you do the work to show your
protocol is secure.
Up until now, we haven't, and users have paid the price.

(If we eliminate renegotation, clearly this cannot be less secure. If
we add key rotation, assuming we do it sanely, there is fairly clearly
not a problem.)

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

I don't think you understand the point I'm trying to make: it's not
that I can sit down and make an attack taking advantage of
renegotation. It's that renegotation is so complex that applications
don't understand how to use it, and so it's very difficult to ensure
that we've provided the right semantics, and hard to determine how
implementations should deal with it.

With the Finished message it's a different issue: analyzing with
Finished is a pain, because the master-secret gets used as is.

With the core handshake it's a third issue: the standard key agreement
semantics have never been provided, and they should be.

I don't care too much about renegotiation: the handshake fixes,
maintaining the security of the new handshakes, and fixing the
finished message are more important.

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

Sincerely,
Watson Ladd

>
> regards,
> Nikos
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin