Re: [TLS] Proposed text for removing renegotiation

Watson Ladd <> Tue, 10 June 2014 17:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9DE0E1A022F for <>; Tue, 10 Jun 2014 10:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pwxeDxEu_ydG for <>; Tue, 10 Jun 2014 10:04:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5D2E1A0040 for <>; Tue, 10 Jun 2014 10:04:19 -0700 (PDT)
Received: by with SMTP id 79so3839652ykr.31 for <>; Tue, 10 Jun 2014 10:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U1NtEXCSflOtU93UlA6/opL3l8w93hewlkPlrUW6jHc=; b=0AxZjVqRA5tXEgMjWcBD6+M6R5xH+85tmUZWMbCMs9dTbwQ93pU6VU4nLQS5DDPkJW NwyltiiJas/gVnvanjyMaNZ5OItRWtAWs5gDc32VJZ0LB9OeYaUC0nr4wIcXlZlu0obT no9VabpAf/cTEq4WKqtl6o3HIPFvzhxE2j9ZAD0Jo/sePWsmhiAmA7p3yFCM6OV4oSRZ Tnlu3XPZ7eBp5oqiVL/smc90P7Ysd2L2eubLW3yqBKVnDzd9AB1epg9OvB3gM09p4LCL rlFoGUF0tdKwIM2OkCDNpB0U1taDJlu9hEx3pvTPfFpKIRokZiC/8wl8HvVBub6TDlFN h+ug==
MIME-Version: 1.0
X-Received: by with SMTP id 65mr4984353yhd.107.1402419859182; Tue, 10 Jun 2014 10:04:19 -0700 (PDT)
Received: by with HTTP; Tue, 10 Jun 2014 10:04:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Tue, 10 Jun 2014 14:04:19 -0300
Message-ID: <>
From: Watson Ladd <>
To: Nikos Mavrogiannopoulos <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] Proposed text for removing renegotiation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jun 2014 17:04:21 -0000

On Tue, Jun 10, 2014 at 5:19 AM, Nikos Mavrogiannopoulos
<> wrote:
> On Mon, 2014-06-09 at 11:17 -0700, Martin Thomson wrote:
>> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <> 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

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