Re: [TLS] CCS and key reset and renegotiation

Nico Williams <nico@cryptonector.com> Thu, 05 June 2014 15:40 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6691A1A01F7 for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 08:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpirwN4cTq1T for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 08:40:39 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 979B01A0167 for <tls@ietf.org>; Thu, 5 Jun 2014 08:40:39 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 5AD1131805C for <tls@ietf.org>; Thu, 5 Jun 2014 08:40:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=EuDthbdhwLYUCjMALJBBKH1IyFc=; b=EerwrfQiovL /jC0aaFbEEj/vXLvKntMfu1r29UG989iubADyg06xebDltSmr4yAQMkuyOEENQJn frgOM9ACVCBI9EQvY34+/jyk2veUhusUGq8uagSnNNwmZ19UCLpYUCvsBllBTnud OKsu0EuvV+95AyjWP61ZwK3TzjwD2Y2I=
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id D80B8318059 for <tls@ietf.org>; Thu, 5 Jun 2014 08:40:32 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id bs8so10718617wib.12 for <tls@ietf.org>; Thu, 05 Jun 2014 08:40:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.93.202 with SMTP id cw10mr16675198wjb.95.1401982829712; Thu, 05 Jun 2014 08:40:29 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 5 Jun 2014 08:40:29 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com>
Date: Thu, 5 Jun 2014 10:40:29 -0500
Message-ID: <CAK3OfOi9CGG6hwh8Y6PBLsLRL7mf2CGa_kKcEo79-8uhTEP4=Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pN_AfuicMqptzGA5jE9DdI6v8LM
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] CCS and key reset and renegotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 15:40:42 -0000

On Thu, Jun 5, 2014 at 10:09 AM, Salz, Rich <rsalz@akamai.com> wrote:
> 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.

The good news is these bugs are getting found, and that this and
Heartbleed aren't protocol bugs -- sure, the protocol made it easier
for programmers without automatic bounds checking and so on to screw
up, but, the problem is the lack of bounds checking and so on.  And,
frankly, this bug is just the result of failure to keep one bit of
state: if there's no key, then CCS should cause a protocol failure --
the sort of bug that the protocol can't be blamed for, like the goto
fail bug.  I know the discoverer thinks that the description of CCS is
to blame, but I don't.  I think it's just this one bit of state, not
kept or not checked where it matters.

The bad news is that there's no plan to replace OpenSSL with something
better; there is nothing better with sufficiently friendly licensing
terms.  What other serious bugs lurk unknown to the public?  There's
no light yet at the end of this tunnel.

Nico
--