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

Dave Garrett <> Sat, 04 June 2016 06:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 638EB12B02B for <>; Fri, 3 Jun 2016 23:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AtAfKY77kw_0 for <>; Fri, 3 Jun 2016 23:26:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF95312B009 for <>; Fri, 3 Jun 2016 23:26:03 -0700 (PDT)
Received: by with SMTP id n16so13292207ywd.2 for <>; Fri, 03 Jun 2016 23:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=cs1X8qqtnBiMZTeSgLp6zW+zZcqGacn+DFlAhISbDAY=; b=xMnZex5LdsRlWQo1JsSZiaTUDf5Tb6suhAqoIpitObpywclt97MXYvkVLYDjyEfLHl jVydHPOR3oW/onIUHFkUNQVhk5gC/9BZFtphWkgm/mIiQUhFJizf8rwXUKSSKhGc5XbE CC7x1d2UQZBBB95N5/D1HuyT4X1MX7gb87wNQ+ARiTuCcBcuL2jhinMdXZRXpxE8Towy AiXlsvCGpuCaUgyrGlAFnNzxmZlUiydXNDfMYaUSozvpjMQXt6TGXyKKDgF/NLp0+N+0 U+aKScfl066IWbtoWA+1YwWkOKUhj1Q10AqsS46ZjkcoENkpoWHtaLnKwE7OIDTbypSa xqnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=cs1X8qqtnBiMZTeSgLp6zW+zZcqGacn+DFlAhISbDAY=; b=Xugbwtz3FaxkZUAQ+pvXSM3UKkZ4Zoaq4ZAz4wqNu5o3nmvuVtVHoNVvfjPVImYVb3 5zISwl/vKKfZDrMbL3rIqymOhtGlaYiYGqpH4nLUx+ujTuu+MKjt+bac5h05jh8E41Ew xxDmx3U/ttbW3GytSoUKptfDW1YnqM0MuRUiWkbeGLJA+P2x7tByf42GW/w+QPAkkVMH yhCrZ//Ue6zq3N9iD4eGtx4Kfl6BeiZGoJbJyFfNIu5jINZCgK4eWKebd1hJKahOOATj ySYhNsGEpq2ncCoUcOYu5aKmwnxFmOuJskY5TkRvCwBah+GAYgmZlQWFy3q4WkSrZDeO Bb1g==
X-Gm-Message-State: ALyK8tLEWoZnDNXGjCL1bgo+pIGzUXSzYU3XpQfHs78Km9BslkMB7+HriwNzJ7eOgdRY+Q==
X-Received: by with SMTP id 140mr4976165ybn.112.1465021562993; Fri, 03 Jun 2016 23:26:02 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id w185sm5489424ywe.1.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 03 Jun 2016 23:26:02 -0700 (PDT)
From: Dave Garrett <>
Date: Sat, 4 Jun 2016 02:26:00 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
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 06:26:05 -0000

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? No objection to avoiding trial decryption, though.

The general expectation I would have for doing double encryption here would be to encrypt TLSCiphertext normally with the application traffic key and TLSCiphertext.content would be the real unencrypted length plus an aead-ciphered struct of the message which is encrypted with the relevant key. (the unencrypted length would be the inner encrypted block's length, in this scenario)