Re: [TLS] Proposed text for removing renegotiation

[Watson Ladd <[e-mail]>]

On Tue, Jun 10, 2014 at 5:19 AM, Nikos Mavrogiannopoulos
<[e-mail]> wrote:
> On Mon, 2014-06-09 at 11:17 -0700, Martin Thomson wrote:
>> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <[e-mail]> wrote:
>> > Could somebody elaborate on what is that issue and why does it need to
>> > be solved? (it is not even mentioned in the TLS 1.3 charter) As someone
>> > who follows the mailing list that proposal comes out of the blue with no
>> > context whatsoever.
>>
>>
>> I think that this has been covered in the thread, but piecemeal:
>
> Not in my opinion. The arguments being presented are very vague, as the
> ones you quote below.
>
>> * Renegotiation is a major source of security issues, both of the "we
>> screwed the TLS design up" sort and of the "my application didn't
>> realize that these things could change" sort.  There is a clear desire
>> to remove features that enable either sort of problem.
>
> Could you please cite these security issues. In the 17 years of the
> protocol I have only seen one.

Triple Handshake depends on renegotiation confusion in part.
>
>> * Renegotiation is just more protocol complexity.  Removing it
>> potentially makes implementations simpler.
>
> Where do you base this conclusion? Have you implemented it and you found
> it complex, or have you tried to model it in some formal model and was
> impossible? Renegotiation, is one of the most simple parts of the
> protocol (Martin Rex argued for that in a previous e-mail and I concur).
> Your proposal to solve this "complexity" is more complex than the
> current solution.

Quick: what is the proper response when the Certificate changes
between a negotiation and a renegotiation?
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.

Show me a formalization of renegotiation semantics, and I might be
convinced otherwise. But to say that it is
"not complex" belies the experience of implementors, theorists, and
the past 17 years of security

The only thing not complex about it is making a terrible
implementation that fails to do the right thing.

You are right this is not in the charter: security was not placed in
it, despite repeated failures on the part of this WG to assure that
data protected by TLS is not folded, spindled, mutilated, or read in
transit. The complexity of the TLS protocol and its resistance to
modeling is directly responsible for many of these flaws, while
encouraging the continued use and expansion of several rather poor
>
>> I think that either might be sufficient justification for removing the feature.
>
> Not to me. I believe that unless hard evidence of the problems are
> presented, this call for action here is unwarranted.
>
> regards,
> Nikos
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls



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