Re: [TLS] CCS and key reset and renegotiation

Nico Williams <> Thu, 05 June 2014 16:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 144F51A0220 for <>; Thu, 5 Jun 2014 09:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5jV9CUrzoryW for <>; Thu, 5 Jun 2014 09:27:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D51011A023E for <>; Thu, 5 Jun 2014 09:27:27 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id A40B72007F008 for <>; Thu, 5 Jun 2014 09:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=GuGpxR71gwuyuYlZ+7zJTHtwTYE=; b=iHzife0av3C DzG0CZCXyR6RFA6uqS/3X58hG6BKhsaV/4RqSl1CbgfyOBMG9tet/7brs57NN0sH LXTTE08UCFaW2VbHRhfqlmtdWdVMB4W2/sG/ZeOP3ftg707G32FYtUvtE9dhLTsN wRi39A69gpzsFqjyaDnU0sSrXv6wVlbE=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 492272007F005 for <>; Thu, 5 Jun 2014 09:27:20 -0700 (PDT)
Received: by with SMTP id f8so10859251wiw.2 for <>; Thu, 05 Jun 2014 09:27:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id v1mr17178243wiw.5.1401985638115; Thu, 05 Jun 2014 09:27:18 -0700 (PDT)
Received: by with HTTP; Thu, 5 Jun 2014 09:27:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 5 Jun 2014 11:27:18 -0500
Message-ID: <>
From: Nico Williams <>
To: Martin Thomson <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: " \(\)" <>
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 16:27:30 -0000

On Thu, Jun 5, 2014 at 10:53 AM, Martin Thomson
<> wrote:
> On 5 June 2014 08:41, Salz, Rich <> wrote:
>>> 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?
>> Because the line between “often get it wrong” and “cannot be implemented” is
>> often a very thin one and it’s better to be cautious and safe, then
>> pedantically correct and usually broken.
> I tend to agree with Watson here.  This is a problem that happens
> during the initial handshake only.  Maybe we can design the handshake
> to ensure that CCS cannot be abused for TLS 1.3.  But I don't see how
> this vulnerability extends to subsequent handshakes or rekeying
> exchanges.

A single bit of state was not kept or checked.  How do we prevent that
sort of implementation bug with protocol design?  How could we prevent
the goto fail bug with protocol design?  (Well, DANE helps, to be
sure, by cutting out the PKIX.  But really, even then there will be
plenty of opportunities to commit bugs of these types.)

At some point using silly implementation bugs as a justification for
protocol design decisions... will probably lead to bad protocol design

There are cases where I think that protocol design decisions do impact
implementation quality.  For example, using ASN.1 w/ BER/DER/CER in
new protocols is asking for trouble because a) cheap tooling is still
not widely available, b) BER is very redundant, and redundancy doesn't
help programmers get it right.  ASN.1 w/ PER, or XDR -- these are
superior to BER.