Re: [TLS] Proposed text for removing renegotiation

Nikos Mavrogiannopoulos <> Tue, 17 June 2014 07:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D616B1A0272 for <>; Tue, 17 Jun 2014 00:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.553
X-Spam-Status: No, score=-7.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 968SC6CbiuRd for <>; Tue, 17 Jun 2014 00:36:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 455981A005C for <>; Tue, 17 Jun 2014 00:36:41 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id s5H7adJf028665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Jun 2014 03:36:39 -0400
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id s5H7ab0C029506 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 03:36:38 -0400
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Watson Ladd <>
Date: Tue, 17 Jun 2014 09:36:36 +0200
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
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, 17 Jun 2014 07:36:44 -0000

On Fri, 2014-06-13 at 08:34 -0300, Watson Ladd wrote:

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

Indeed, but this is an easily unsolvable issue. That can be easily
avoided on the implementation side (and gnutls is does not allow that).
I have numerous times asked to clarify and better specify this part on
the past.

> Furthermore, renegotiation makes writes block on reads. That can cause
> pain for event based systems.

I don't understand what do you make by makes writes block on reads.
Renegotiation is the same a negotiation in TLS. The same issues that
exist in the TLS handshake will exist in the rehandshake. Nevertheless,
I've used many even-based systems with TLS with no issue.

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

The whole thread is about dropping renegotiation _and_ replacing with a
mechanism proposed by Martin Thompson.

>  No, you do the work to show your
> protocol is secure.
> Up until now, we haven't, and users have paid the price.
> >> 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 Search TLS:
> "we do not model renegotation/resumption"
> Analyzes the renegotation fix, a
> full 3 years after the fix was proposed and adopted, and TLS does not
> meet strongest security model.
> Renegotation isn't mentioned.
> I did skip over a few papers but the message is clear: renegotiation
> is not currently amenable to analysis.

Interesting observation. However, the fact that renegotiation has not
been modeled in some papers doesn't reveal much except that the formal
protocol verification lags behind protocol design. If you check the
papers that you reference you'll notice that it is not only
renegotiation that they don't model. The first one doesn't even model
ciphersuite negotiation which is the basis of the protocol. The second
does mention that renegotiation can be modified to avoid a stronger
adversary, i.e., an adversary that can learn the previous session keys.
That's an interesting paper, but whether we really need to protect
against this adversary is really up to discussion.

Most often in academic papers (with the exception of mitls work) they
simply model a single ciphersuite and prove it secure; then in the next
month you see an new attack on the same ciphersuite that was proven
secure, because the majority of the protocol interactions were ignored.
That does not show that we need to drop all the protocol options and
only allow for RSA-AES-CBC for example (which was proven secure numerous
times prior it was broken). If we had followed that path and dropped
ciphersuite negotiation, renegotiation, and session resumption, only to
allow the "proven" secure options, now TLS would be broken and we
wouldn't have a way to fix it.