Re: [TLS] CCS and key reset and renegotiation

Viktor Dukhovni <> Thu, 05 June 2014 15:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE8FA1A02B3 for <>; Thu, 5 Jun 2014 08:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UlGlv_T7AIyi for <>; Thu, 5 Jun 2014 08:23:59 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E0D71A0167 for <>; Thu, 5 Jun 2014 08:21:44 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 992722AAB4F; Thu, 5 Jun 2014 15:21:37 +0000 (UTC)
Date: Thu, 5 Jun 2014 15:21:37 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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 15:24:04 -0000

On Thu, Jun 05, 2014 at 11:09:30AM -0400, 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.

A STOPTLS feature could also be useful in the Postfix (TCP) connection
cache.  Because cached TCP connections move between processes
through file descriptor passing, but serializing the SSL state of
an active SSL connection is difficult, we currently can't cache
TLS-protected TCP connections.  If we could STOP TLS before moving
connections into the cache, and resume with a handshake over
cleartext (using a cached TLS session, session ticket, ...) that
would make it possible to cache TLS connections (that negotiate
TLS 1.3 if STOPTLS is a required or negotiated peer feature in