[TLS] judging consensus on keys used in handshake and data messages

Joseph Salowey <joe@salowey.net> Wed, 06 July 2016 17:40 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BD16D12D5AA for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 10:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=salowey-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Vg1uNo82iPtX for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 10:40:14 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 2E91112D528 for <tls@ietf.org>; Wed, 6 Jul 2016 10:40:14 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id m2so120261831qtd.1 for <tls@ietf.org>; Wed, 06 Jul 2016 10:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Y+750lHL0e9SukotIbJWMWN8ysz8nBrNiBAKZcmwdIQ=; b=wi2XEUOQ7Dl5ObfX1gAucbMPxRVVKsqKJ0opzRVD6Q0Jsd4+DfUK2vRmrEhrKOMSBG /vbZGevg/FB2+wPCdxl08MuC3tTNfcMxsZpDwp3j4rDtt/V8wAhPgZG7fmuO+bCLqpzA DhKN/0iu0tl17B6Ck2aBxFNNw7ZXooV6EFyKWL+KJI9S6DkSO++5LhG0vuRbuooYggEf SVkMtvw7juXsy0vQYG4K3LF50NOXPyrP4u6oII8vhHO/elLqLraBrgZYR5pP5N/86/2U LImnoa/Cy8TMEixLhVd8v9VMDlAsAL30+nmMvfl0ofGXG9Cf5krQucR1uYRArmqfw/7x 1E7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y+750lHL0e9SukotIbJWMWN8ysz8nBrNiBAKZcmwdIQ=; b=nG9dOvRhG2otOAhknyUQtCdtw6s2Yao1jdHdxn9jjzNSPHowl2b5ap2rLutXvwsxsW JbKyPvvqWWzYAN7JCDLadNhv1XCsOjr5bX6kbDr9DSB7InSIyHAo53gIv5u2SvwtRm52 fYAMtmTL2GmGL01//lfL8AOqBKeDWVXqN8cvhbKEHGczCefOSrQ9dAea6I+8h+vTNTcD o7F4HBf22gkz15sQy47FTVZJUgjsrUrrqX0zWMfUSyYMGULkiN7H7x3T0n5uPRMrWyNY XW1Ij/96YVLMb0vK9fnce9M7XkFSGeuD7ss2UMGQE9UqAbe1kqhLjEOzCLH9iDcoBFYs nDiQ==
X-Gm-Message-State: ALyK8tK0L7gCIOt4hlIyeCB6QtftXt4qVCSqknmhwjBl99DQbJhUTFbGP3E0syBoi9g+KvDq/yxjRET05EVbaw==
X-Received: by with SMTP id w29mr35919503qtb.99.1467826812999; Wed, 06 Jul 2016 10:40:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 6 Jul 2016 10:39:53 -0700 (PDT)
From: Joseph Salowey <joe@salowey.net>
Date: Wed, 06 Jul 2016 09:39:53 -0800
Message-ID: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11444b06c7fb7a0536fb0fb9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sF1CPxxb4tko_-JOT2ZF4jab32g>
Subject: [TLS] judging consensus on keys used in 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: Wed, 06 Jul 2016 17:40:17 -0000

We are the unenviable position of calling consensus between three choices

- Option 1 - use the same key for both handshake and applications messages.
- Option 2 - restore a public content type and different keys.
- Option 3 - separately encrypting the content type.

At this point the consensus is rough.

The first option we would broadly characterize as supported by the
implementers because they can’t see the harm in using the same key but
opposed by the cryptographers because it makes the proofs harder making
mistakes easier to miss.

The second option as supported by researchers/cryptographers because it
cleanly separates the keys used but opposed by the implementers because
it’s unnecessarily complex.  In general, privacy advocates do not support
this option either.

The third was not really discussed at all and it’s not clear what is the
impact to security proofs or implementations.

As we see it the privacy concerns are somewhat of a moving target, however
not encrypting the content type seems worse for privacy than encrypting it.

We are looking to eliminate option 2 and choose 1 or 3.  If you are in
favor of option 2 then we need to know if option 1 meets your needs, if
option 3 is better than option 1, or if you feel that the only viable
option is option 2.


[0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBuiNA