Re: [TLS] Proposed text for removing renegotiation

Nikos Mavrogiannopoulos <> Fri, 13 June 2014 08:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 474721A0312 for <>; Fri, 13 Jun 2014 01:43:05 -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 sAvrwKy3nlxW for <>; Fri, 13 Jun 2014 01:43:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 78E0F1A030E for <>; Fri, 13 Jun 2014 01:43:02 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id s5D8h0br031000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 04:43:00 -0400
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id s5D8gwZp007417 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2014 04:42:59 -0400
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: Watson Ladd <>
Date: Fri, 13 Jun 2014 10:42:57 +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: Fri, 13 Jun 2014 08:43:05 -0000

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.

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

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

> 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

>  the previous renegotiation bug,

It was addressed long time ago.

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