Re: [TLS] Proposed text for removing renegotiation

[Watson Ladd <[e-mail]>]

On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> On Tue, 2014-06-10 at 14:04 -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.

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

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

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

But as for theory vs. practice, that is false: there have been secure
key exchange protocols since the dawn of cryptography. The reason the
protocols have been hard to analyze is gratuitous complexity: there is
no reason TLS could not have used a secure key exchange as IPSEC
eventually did.

Where is the usecase that needs renegotiation in TLS 1.3? I've not
seen it: we've provided alternatives for all of them. Why do you care
what we do to provide an easy protocol to analyze? If there is a case
for keeping renegotation, make it: don't a

>
>> 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, the previous renegotiation bug,
virtually every paper on the TLS handshake until miTLS, etc. Can you
point to someone providing an adequate explanation of what
renegotation does?

>
> regards,
> Nikos
>
>



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