Re: [TLS] Closing on keys used for handshake and data messages

Ilari Liusvaara <> Sat, 04 June 2016 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0ADF912D152 for <>; Sat, 4 Jun 2016 02:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ev_8CdrzcaDF for <>; Sat, 4 Jun 2016 02:51:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D97D712D10D for <>; Sat, 4 Jun 2016 02:51:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8207414E1 for <>; Sat, 4 Jun 2016 12:51:12 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id gIpxgofBZ2R7 for <>; Sat, 4 Jun 2016 12:51:12 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2C945C4 for <>; Sat, 4 Jun 2016 12:51:12 +0300 (EEST)
Date: Sat, 4 Jun 2016 12:51:11 +0300
From: Ilari Liusvaara <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Subject: Re: [TLS] Closing on keys used for handshake and data messages
X-Mailman-Version: 2.1.17
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: Sat, 04 Jun 2016 09:51:18 -0000

On Sat, Jun 04, 2016 at 02:26:00AM -0400, Dave Garrett wrote:
> On Friday, June 03, 2016 05:54:53 pm Joseph Salowey wrote:
> > Unfortunately, the TLS record framing is not easily compatible with having
> > multiple keys used simultaneously: because we encrypt the content type, it
> > is not possible to use it to determine which key to use to decrypt. We
> > examined a number of proposals which would allow you to simultaneously have
> > encrypted content types and separate keys, but they all appear to be
> > nonviable for one reason or another:
> > 
> >    - Trial decryption has serious implementation problems
> >    - Double-encrypting handshake messages in both the handshake key and the
> >    application key does not actually provide the required key separation
> >    - Separately encrypting the content type is inefficient in a number of
> >    ways, especially for DTLS (and would need separate security analysis). This
> >    is probably the most viable of the “try to get both” designs.
> Could someone please elaborate on why nested encryption would be a
> problem?

The problem is that nested encryption does not solve the separation
problem (application misusing keys it has[1] in ways that interact
badly with the (late) handshake[2]).

Essentially the difference is "the generated key is safe to use with
any protocol" versus "the generated key is safe to use for TLS 1.3".

And if the first is not true, proving the second is harder (even if
it should be true, barring massive design errors[3] or applications
doing utterly crazy stuff[4]).

[1] Nevermind it REALLY SHOULD NOT actually have those keys, but only
plaintext access to its own mux stream.

[2] In normal TLS operation, the protocol mux/demux prevents such
interference from actually occuring.

[3] Like grossly broken protocol mux.

[4] Stuff applications have absolutely no legimate business of doing
(if I ever see such things, my first assumption about the cause will
be malice).