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

Dave Garrett <davemgarrett@gmail.com> Sat, 04 June 2016 06:26 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638EB12B02B for <tls@ietfa.amsl.com>; Fri, 3 Jun 2016 23:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 AtAfKY77kw_0 for <tls@ietfa.amsl.com>; Fri, 3 Jun 2016 23:26:03 -0700 (PDT)
Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF95312B009 for <tls@ietf.org>; Fri, 3 Jun 2016 23:26:03 -0700 (PDT)
Received: by mail-yw0-x244.google.com with SMTP id n16so13292207ywd.2 for <tls@ietf.org>; Fri, 03 Jun 2016 23:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.37.13.146 with SMTP id 140mr4976165ybn.112.1465021562993; Fri, 03 Jun 2016 23:26:02 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-185-27-22.phlapa.fios.verizon.net. [71.185.27.22]) by smtp.gmail.com with ESMTPSA id w185sm5489424ywe.1.2016.06.03.23.26.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 03 Jun 2016 23:26:02 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
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: <CAOgPGoB6=eH9059u95RJzt_quCN3+auP2NSx+mxLztePVYqGrw@mail.gmail.com>
In-Reply-To: <CAOgPGoB6=eH9059u95RJzt_quCN3+auP2NSx+mxLztePVYqGrw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201606040226.00867.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/jPitXSzUd2nNr5To4jm5ApizlYw>
Subject: Re: [TLS] Closing on keys used for handshake and data messages
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: 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)


Dave