Re: [TLS] Proposed text for removing renegotiation

Watson Ladd <> Wed, 11 June 2014 11:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF6CA1B2864 for <>; Wed, 11 Jun 2014 04:45:52 -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 R2GfQ3hfPO7H for <>; Wed, 11 Jun 2014 04:45:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A75171A004A for <>; Wed, 11 Jun 2014 04:45:51 -0700 (PDT)
Received: by with SMTP id f10so1476219yha.10 for <>; Wed, 11 Jun 2014 04:45:50 -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=GBtY15G8WStaXcl8om8dL+HoSFoKULUjQL5cmGAtkhI=; b=eBlvwjTgEFnJSNOYoViFAELzT/Nlj5NAfzFYSes5DuKHhXDX+RVrAxq4h6RxnhDjn/ wpu72GeLTUq/PX72xHRGz+rYvrymf3bLo4HXaAtxpzvJSzDs54/dLvNEp9+XsjO6Sg4d YGog87DyLQKd5VdE3UnVTkpL8NZJrIsfpkqPvlU4wM9qxr1NkjOKzWQM+Qg0NyOYzXwH 3kQBHux8TkDtfQpWGHJ1qaNXRCajc/sIzOUwMTd++C3GdA4LSTgktYpSb+4I54wQEljt pH2ntpjYUZgqdI3whm6K4jj09g9Nz8/17qldASWr6x02juc/w/S8GEGhIrgjMtPBJDjH HWYw==
MIME-Version: 1.0
X-Received: by with SMTP id a9mr4956615yhi.83.1402487150808; Wed, 11 Jun 2014 04:45:50 -0700 (PDT)
Received: by with HTTP; Wed, 11 Jun 2014 04:45:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 11 Jun 2014 08:45:50 -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: Wed, 11 Jun 2014 11:45:53 -0000

On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos
<> 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