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

Yoav Nir <> Wed, 06 July 2016 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1445312D10E for <>; Wed, 6 Jul 2016 14:11:46 -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 30_mlJsGjc8u for <>; Wed, 6 Jul 2016 14:11:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B72CD12B04E for <>; Wed, 6 Jul 2016 14:11:43 -0700 (PDT)
Received: by with SMTP id z126so125997408wme.0 for <>; Wed, 06 Jul 2016 14:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HoEGTsoy31TnTsE0aBdYKG6zbcefcWsZF7tnAEc+OOw=; b=MuV9iTzEYuO34u9zwjYZX08vOPN1l+D0GMQ//l4EWkpkaiaZYyuxUvKbZrQyNB621Q VWf6J6AH7l+TJE9uCjHRvkivQnVWOVtlvKEn0wjkdqRBr5MhPBKC6MHET9+Rbfn1uSyj aIS+6indQ0qAB7kLZmcZIIXn5q1UIekMu/cQddKlMdQ6HKNsYuQ1HIOaogyT6VVci6ZH hLToVT0eJnHefMaRjIlUuop1LB4sTiVsLIEGwfnUAV/7wfdicQIJrnTYKyCmVAZBWKNV NNOqYJY76fSSGUokuGr7gd6t8CIrAwSG41zqphRhn9M+FV+pTB5o5CPhACVXHFc81iXu QXUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HoEGTsoy31TnTsE0aBdYKG6zbcefcWsZF7tnAEc+OOw=; b=FfE0JMcme51TxFP1qnXwVSE8WLP1lCsyhMqn32CoeBiz19lqe/vKYrncneVRzY6hU1 0Xyg9oxaK56FB3u+SXi0xENrhpU254fJf+M4WYbtTRxMEz24VaIe7kDOecm0iP57sWz5 TkvFalrq41QKJO9LklrLXJV1CKrH33F/tMJ0Q7OwBzl3uBT85QUJ+Uc0zonYt7NyoMJ9 nCnqPwvSkgmgW89r19IDS4ycBLBdr2dUivfKOHkNlHZ1GGiSPyt0+gQ/QRF/Z9nWXU/2 qqq/7/dV6VWJ2GWtVi3HITvDjfxoVpoS4S+p7zXFxpNpWCSHY9lP1apQQGH0fwaxg7mE edYQ==
X-Gm-Message-State: ALyK8tJ255vodafeiW50NhAIkNbP8FzI7EnJmJH7GDAZKsffTthCrzh7XHNkTsEwMHJEnw==
X-Received: by with SMTP id 194mr24063696wms.75.1467839502044; Wed, 06 Jul 2016 14:11:42 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k6sm4660279wjz.28.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 14:11:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 07 Jul 2016 00:11:39 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Joseph Salowey <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] judging consensus on keys used in 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: Wed, 06 Jul 2016 21:11:46 -0000

Hi, Joe

> On 6 Jul 2016, at 8:39 PM, Joseph Salowey <> wrote:
> We are the unenviable position of calling consensus between three choices [0]:
> - 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.

I will re-iterate my opposition to option 2. Some occurrences on non-application data records within a TLS session are initiated by user action or application state. Best example is when the user sees a login page and clicks the button that says “Log in with certificates…” causing (in TLS 1.2) a HelloRequest to be send and a renegotiation with client certificates, or (in TLS 1.3) a CertificateRequest to be sent followed by the client sending a certificate. This is not some theoretical weakness. This is real information disclosure. With TLS 1.2 you can look at the Wireshark screen, point to the handshake record in the middle of the TCP flow and know that this is where the user pressed the button.

Of options 1 and 3, I can see that #3 is theoretically better, but the design seems too baroque to me. I hope it can be done without adding a whole new block operation to each record, and I prefer the simplicity of #1, but I’m not really opposed to #3. IIRC there were some cryptographers who were concerned about #1. We haven’t heard from them that #3 solves their issue, have we?