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

Hannes Tschofenig <> Wed, 06 July 2016 20:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B68912D1ED for <>; Wed, 6 Jul 2016 13:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AsciQYlOiPi6 for <>; Wed, 6 Jul 2016 13:00:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05B3312D10F for <>; Wed, 6 Jul 2016 13:00:06 -0700 (PDT)
Received: from [] ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0Ma1pn-1b0Cdw1Mvn-00LjAA; Wed, 06 Jul 2016 22:00:03 +0200
To: Joseph Salowey <>, "" <>
References: <>
From: Hannes Tschofenig <>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 06 Jul 2016 22:00:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Ks9oOICuqi6bvavRF6iVnAm0BvbFmfkBp"
X-Provags-ID: V03:K0:1Kpc5PKjC1bFGUDxRLsTjtSXUJRPWLB/uHwWObEp3UTjGCI+qbq 0k4Yn2ctJEEKkpVzCBeNNfQvZo9XrI01YB2M7wkM0ppNOmPSPuh1zo3XbqsfxGUGKShe/Oi hNPHEOM+Nbn5KhLURU+OEl9/w6E2hAYELsfEX3/doX50CgFA2wLI0Wjs2b0lK3MVwJVFLFd +4OLMnhD6gCExnpy/Yspw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Fe2PBzmEPpM=:MLPhau7RsScTsYvjZCnh3s TB/ILiJ3BBKf6x5bgyO+HDfe7KSHAmsqcBdnl3Q9XW+5UcjzOCflOEAOrPeJh9vbycgCUF9SD 6qfvfdWvAUrOXqFvfkLtlB4jwNLIrwQN1lGOJVjQRAEg8dQE7arAcAZP0M+Em4OH0ahhE2bTW PGwKcK5O1AZJDcJkQ0xU/iAfN/g5bSFywyXCQZ1f1oUjkhstDKSJ0NOPddlBcM6kOjSRAU/1U v5F4xxzoG0D9/ZoO2U9zX+0K/IqESSIOeZL1X5fkfGbz0zEzX7+AEcb+g8yZTzs755AY4sAkQ v1P5EDXIM0/OpfXPmH0XlNi4+Pt2POw2HhSfS4woAlhyrDvy3sfpkXwutkbIrya2q7NY/8ggK w4ggc6f5OSCgnicpv/QmdJeGO1zsIbUF5jLsllDV9HhfZrOdocXTMtjgDPbC8jhj9ctvsWn1s 3+U0l1QYryLPZBbzl2rEkC/Pw+XRdcxc5567/VQWmshhmzt0gFuCsepeBVf6OouT8HZf6rBbD 3UR+GTzBDwXbCJHMtSIxV4UoJyzzcyxiqAAMyJUCZJ2mwMG5PQb9xpIFr9YvwHYCfrL3uCeJ+ aGeT5DlUBMTOXPdsxPfbW+cjdmtAD+A+1SHfmYMNQzk1atfBlib/3astDWkZEresd8vSKE7nM HNG673XqpHbv5+cJ1JuvKRuStuJTKyC6bplFtw/kEiM+z1HCCsu9WnTH6/sq9mlwtnX23IJ41 uTR9JkNxgQpPYQT3Cc5VVhpb/10QwP4vjpU4RKu1cz6cNYy3aegFJopdRro=
Archived-At: <>
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 20:00:09 -0000

Hi Joe,

it might be interesting to note that in the context of the DTLS 1.3
discussion with Ilari it appears that the epoch exposes handshake
messages (vs. application data) since you need a way to find out what
key was used to encrypt the message (and msgs may get re-ordered or lost).

So, I claim that even if you manage to go for option 1 in TLS 1.3 you
will most likely have a kind of option 2 in DTLS 1.3 (unless you get rid
of the epoch value, which is of course possible).

This does not really answer your question but I don't have a strong
opinion between #1 and #2. Separately encrypting the content type sounds
feels a bit too radical to me.


On 07/06/2016 07: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.
> J&S
> [0]
> _______________________________________________
> TLS mailing list