Re: [TLS] CCS and key reset and renegotiation

Jeffrey Walton <> Thu, 05 June 2014 21:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DDB71A0292 for <>; Thu, 5 Jun 2014 14:52:07 -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 p1hjcdjc6tEC for <>; Thu, 5 Jun 2014 14:52:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BB751A0188 for <>; Thu, 5 Jun 2014 14:52:04 -0700 (PDT)
Received: by with SMTP id la4so1965381vcb.0 for <>; Thu, 05 Jun 2014 14:51:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=kIjvRXLij8Tz7jZi34riQXtNm9OPRmiQRAL1Sj31LQ0=; b=SGL1AuoecLwWxtRvmJmxS8jQCX/CB7iOqg6Mo4ojISawNotmDsuL9ZVZhgqvSJRyii MFZJIQvyxOR0n44QGZijf+2O9crC7183gBAAPPhrfFbjkW/cB0QChPcyxdhj2fMEnFXL 23l8xPK8qwjR9NRJddFqlxB1vo3w9PAFd/WT/Hm6yPqj+hDgxpq/i1EPpvZ1tahlUnKM vgB2q6/nhfFMtOlrP4QnmzQyyDRFbGYfSMv+rvC2ViZuM1XvyDTHmHuo1pvjSeVIud4k nT+f7Q7oomikn3IWNBKqRjdjE1+VSb1A5VmZI24Wxq6qJtnX4hPVhOcLtnyjqmWGHOpX LcFQ==
MIME-Version: 1.0
X-Received: by with SMTP id sa13mr685452veb.44.1402005117383; Thu, 05 Jun 2014 14:51:57 -0700 (PDT)
Received: by with HTTP; Thu, 5 Jun 2014 14:51:57 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 5 Jun 2014 17:51:57 -0400
Message-ID: <>
From: Jeffrey Walton <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] CCS and key reset and 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: Thu, 05 Jun 2014 21:52:07 -0000

On Thu, Jun 5, 2014 at 11:25 AM, Watson Ladd <> wrote:
> On Jun 5, 2014 8:12 AM, "Salz, Rich" <> wrote:
>> Have folks seen this yet?
>> I think it adds weight to my concern about using ChangeCipherSpec to do
>> key reset.  I still prefer the trade-offs of having a “slow the TLS but keep
>> the TCP layer open” and starting over.  Much simpler to prove it’s correct.
> What can change when that happens? Furthermore, rekeying is a matter of
> getting more PRF output: how does that introduce security concerns.
> I don't see why the incompetence of implementors should govern our
> decisions. If something cannot be implemented correctly it must be removed,
> but why is rekeying such a thing?

I'm reading two points in that last statement: first, some
implementers are incompetent; and second, the TLS WG does not make bad

For the first point, I think its too easy to blame an implementer.
Perhaps there's a gap that needs to be addressed for implementers. Has
the TLS WG considered providing a comprehensive test framework to
ensure their designs are realized in an implementation?

The working group is in a unique position to offer the best and most
complete set of tests. They are in that position because they
understand what they want, they know why they want it, and they know
what they rejected. So a testing framework with positive and negative
self tests would probably be very helpful to implementers. And that's
all implementers, and not just the ones that are labeled incompetent.

Plus, the implementers should *NOT* be asked to create their own test
cases. That's simply bad engineering, and the problem has been known
for years. Gutmann and Anderson talk about in their respective books
on security and engineering. Those books are 10 or 15 years old, so
its not bleeding edge knowledge.

For the second point, Authenticate-then-Encrypt has proven to be
problematic for years. I would not blame the implementers or call them
incompetent for subtle problems in the construction. Especially when
it took a formal analysis by practicing cryptographers to uncover and
present the problems [0].

The problems with Authenticate-then-Encrypt have been known since at
least 2000 [0]. I question why the folks responsible for the standard
did not acknowledge the problem and provide safer or better
alternatives more expediaently. Nearly ten [1] or fifteen years [2] to
address the [re-occuring] problem seems a bit excessive to me.

The folks responsible for the standard are collectively smarter people
than the folks implementing the standard and using the standard. We
(the dumb users) need the group to act expediently when gaps are

For completeness, CompSci 101 mistakes are an implementers problem.


[0] H. Krawczyk. The Order of Encryption and Authentication for
Protecting Communications,
[1] J. Salowey, et al. AES Galois Counter Mode (GCM) Cipher Suites for
[2] P. Gutmann. Encrypt-then-MAC for TLS,