Re: [TLS] Consensus call for keys used in handshake and data messages

Eric Rescorla <> Mon, 04 July 2016 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A982712D1A2 for <>; Sun, 3 Jul 2016 17:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 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] 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 sVgDbUldrePm for <>; Sun, 3 Jul 2016 17:52:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 348BF12B062 for <>; Sun, 3 Jul 2016 17:52:02 -0700 (PDT)
Received: by with SMTP id b72so29163441ywa.3 for <>; Sun, 03 Jul 2016 17:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VUdfyiuT/fbZdUeZMcG5h8WQasIBBcxdFd9zqP1lhMo=; b=fAPMZ/dMepL2Qk2Vzfvt1TviR8gbtPp0P8ZhIE9YLDMs+OsGMkzXkzsRtaXq8FhuRf IHbH/p+P6Go1v6bZxh2SzJJqrEnFbwSXKdi0M+tfOk3ZGcVdlmPoyUuBxCcsQmlMa6et ys1pr0BMpbPjQN76CAUvaSnJ/hWl8QiGjn1tMvug4lbnVBBuwQIyXx1VfN1tKXLS8cNM 89ObvtWnsemVEg1x7xirmrz+2cZCpaAhDFziE1tAEjKXH9euylGgF6I4keH+qZ3GdKeU Ebu4WisVsdNzToxFNQ1V9/5ZlB2xqAvA9OOLG/uQ3ClXXlNha29zTh87YYE8UoEgnJgQ OAJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VUdfyiuT/fbZdUeZMcG5h8WQasIBBcxdFd9zqP1lhMo=; b=UyKdLyTp4GDzhyqZ5eYRsLoMYGCfl+oYKQDLR3wM6WyDpW4R7eqq44Fbf5HX7o9UaB 1ZnvhoN2U7Gxv6JYo9gvLe8rn8PoSdDusYWjG4nyY8KYQYVXBdK222+0PA2uGuZD9ttQ EhK84tY4VDNXJ1PPFgKvyz8UPH1opkMwLk1BU99G6cuXBde3Rza0wubBITylKnWXhcPy XAhJ26GUjtaTIP+YVw/Q8VuDthsnO7FReiwjqJYcDnfXv2yoK/VGwkfjZlbc9MZPOlgL sGvFFse4K4mOQYImQzQZUxoIbVrzDaR9dpEVbxpn7i85YD6wAesLc0s+LgTqNQf722B1 fC+A==
X-Gm-Message-State: ALyK8tKKB+JpKXAxVixUvbbqEdYhbQT20JmaHkzOKn3CTbhpEWx4MoEqWA+kkrNb69K6h4nDLynLh6LlydLgiw==
X-Received: by with SMTP id 193mr5554340ybd.130.1467593521388; Sun, 03 Jul 2016 17:52:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Jul 2016 17:51:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Eric Rescorla <>
Date: Sun, 03 Jul 2016 17:51:21 -0700
Message-ID: <>
To: Hugo Krawczyk <>
Content-Type: multipart/alternative; boundary="001a11c03a4e84acb40536c4be98"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Consensus call for 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: Mon, 04 Jul 2016 00:52:05 -0000

I'm not seeing a lot of enthusiasm for this option either.

Do any of the people who were in favor of #1 or #2 want to say they prefer
some variant of this proposal?


On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla <> wrote:

> Nobody seems super-excited about either Option 1 or Option 2, so it's
> at least worth noting that there's one of the options I claimed was
> rejected earlier, namely separately encrypting the content type in
> roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for
> Doug/Felix for prompting me on this.
> NOTE: I don't promise any of the below is secure, though it probably
> can be made so with enough work. Actually doing so is an exercise
> for the reader.
> The basic idea is as follows:
> 1. In each direction generate a separate "content_type_key"
> 2. Separately encrypt the content type from the rest of the record
>    using the content_type_key.
> 3. On the receiving side, first decrypt the content type and then use
>    that to determine what key to decrypt the record.
> The trivial version of this is just to AEAD encrypt the content type
> separately, but this has unacceptable bandwidth and CPU properties, so
> is probably not viable. However, there are more efficient designs,
> which can get the overhead down to modest levels (<= 1 byte of
> expansion and <=1/16 of a block computation/record).
> The obvious construction is to use the content_type_key to compute a
> per-record masking value (effectively an ad hoc stream cipher) and
> then use that to encrypt the content type (or potentially just a key
> type bit) without integrity (though you might later protect it in the
> additional data block under the main key). This gives you an
> encryption function without expansion. If you have a mask function
> which outputs one block at a time, you can use pieces of the block for
> each record (e.g., for record N you use byte N/16) [1]
> Obvious objections to this:
> 1. This isn't integrity protected. This is probably the most serious
> complaint and has the potential to actually leak information about
> the content type unless you're careful [2], even if you eventually
> integrity protect this information.
> 2. It's odd to just use a piece of the AEAD cipher (the encryption
> function), especially if we ever had a really non-composite cipher.
> This can be alleviated by using HKDF-Expand to produce the stream
> of bits.
> 3. Maybe it doesn't get the whole job done, especially wrt the fact
> that we're not rekeying the app data after client auth.
> 4. It's gross. Yes, yes it is.
> I'm not really in love with this idea, but I did want people to know
> that maybe we don't *have* to choose between option 1 and option 2
> in case that changes people's opinions.
> -Ekr
> [0] Note, I'm specifically not trying to protect length here. That
> might be attractive, but my sense is that for the reasons Kenny
> indicates it's harder to get right and I'm generally pretty skeptical
> of length hiding in TLS given that we already have added padding.
> [1] There are some subtleties about not breaking the record format.
> If we don't care, then we can strip the first three bytes and then
> steal a bit from the length to use for "key type" (the length will
> never hage the high bit set). If we do care, then we could use the
> key bit to toggle between "app data" and "handshake" in the dummy
> record type byte.
> [2] Naively, if you try encrypting the whole content type, some
> transformations on the encrypted value will produce invalid types,
> which leaks information if the receiver sends an alert.
> On Fri, Jun 17, 2016 at 1:18 PM, Hugo Krawczyk <>
> wrote:
>> I am abstaining on the choice of alternative 1 and 2 since I do not
>> understand
>> enough the engineering considerations and ramifications of the different
>> choices. Also, I have not put any thought into the privacy issues related
>> to
>> hiding content type and I certainly did not do any formal analysis of
>> these
>> aspects.
>> I do want to say that from a cryptographic design and analysis point of
>> view,
>> key separation is of great importance. It allows to have more modular
>> analysis
>> and design, and prove composability properties of protocols and
>> applications.
>> I believe it has significant practical advantages particularly with
>> respect to
>> "maintaining" a protocol, namely, making sure that changes and extensions
>> to a
>> protocol are secure and do not jeopardize its security. The more modular
>> the
>> design the easier it is to reason about changes and additions to the
>> protocol
>> (and for a protocol like TLS, future changes and adaptations to different
>> settings are unavoidable).
>> As for the specific cryptographic considerations in TLS 1.3, I would have
>> "fought" greatly to preserve key separation at the level of the basic
>> handshake
>> protocol (three first flights). It guarantees that the application key is
>> *fresh* at its first use for protecting application data. Freshness means
>> that
>> the key can serve any purpose for which a shared random secret key can be
>> used.
>> (In contrast, a non-fresh key, e.g. one used during the handshake itself,
>> can
>> only be used with applications that are aware of how exactly the key was
>> used
>> in the handshake.) Since my understanding is that the current
>> base-handshake
>> specification does preserve the freshness of the application key, I am
>> happy
>> with that design.
>> The issue of using the application key to protect post-handshake messages
>> is
>> more involved. First, post-handshake client authentication authenticates
>> ("a
>> posteriori") the application key but only after this key has already been
>> used.
>> In this sense this mechanism cannot possibly achieve key freshness for the
>> application key. The best one can hope for is that this
>> post-authentication
>> authenticates the key without jeopardizing its use in the particular
>> application
>> it is intended for, namely, protecting TLS record layer data. Luckily,
>> this can
>> be proved. So now the question is whether using the application key to
>> encrypt
>> the very messages that provide post-handshake authentication (e.g.,
>> client's
>> signature) may lower the security of this key. The answer is that it does
>> not.
>> That is, the security of the key for protecting record layer data is not
>> jeopardized by using it to encrypt post-handshake messages.
>> I feel moderately confident about the above paragraph as I have been
>> working on
>> the analysis of client authentication, including (encrypted)
>> post-handshake
>> authentication. On the other hand, I have not studied the effects of
>> encrypting
>> other post-handshake messages such as New Ticket or re-keying messages so
>> I
>> don't have an "educated conclusion" here. I do expect that there are
>> analytical
>> advantages for not using the application key for encrypting these
>> messages but I
>> cannot say for sure.
>> In all, it is good and prudent practice (not just theory) to enforce key
>> separation wherever possible, and I would be happier if there was no
>> instance
>> where the application key is applied to non-application data. But I also
>> know
>> that one has to weigh other engineering considerations and in this case
>> the
>> trade-off does not seem obvious to me. Hence, as said, I abstain.
>> Hugo
>> On Mon, Jun 13, 2016 at 3:00 PM, Joseph Salowey <> wrote:
>>> For background please see [1].
>>> Please respond to this message indicating which of the following options
>>> you prefer by Monday June, 20, 2016
>>> 1. Use the same key for handshake and application traffic (as in the
>>> current draft-13)
>>> or
>>> 2. Restore a public content type and different keys
>>> Thanks,
>>> J&S
>>> [1]
>>> _______________________________________________
>>> TLS mailing list
>> _______________________________________________
>> TLS mailing list