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

Hugo Krawczyk <> Thu, 07 July 2016 10:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0025D12D745 for <>; Thu, 7 Jul 2016 03:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 VjkqJy7jcWwS for <>; Thu, 7 Jul 2016 03:44:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 858C112D74A for <>; Thu, 7 Jul 2016 03:44:38 -0700 (PDT)
Received: by with SMTP id b72so10675015ywa.3 for <>; Thu, 07 Jul 2016 03:44:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8Gprtve30Qg5Pah95gVT88KuYhQzTvbawqz9PyckQUo=; b=G8W65Y/MYkKPuq44xuBDoBGx3yFVoaW4vQNHxGfwLrcXUVHQfXMdFF1zE/D5NfSytj 5hby+9pDszLeVs95L7iJvQTBairSHxqNzE5BP1NXLzJ9kSNzRuas7NAtkT7GGVrkyLvp 3UMZ8Z+x7qzWxyG8a4/oNSz7rUlFXivhx0njyuggfYRwax3mEvLDYedttUpQ6xVjER88 48QYxOIMs+wMW9TfQ0t16TGwZdLzrOl9wbctaeigvIb4QtW8loj3wmY3XkfLFyT8/a/5 TQHld3JfOItfuzxx/uCbtyhT9fTHdGNrpiAYZcAdZpQOav6vmz4bxGZTY4VlGPqiIPoT 9+Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8Gprtve30Qg5Pah95gVT88KuYhQzTvbawqz9PyckQUo=; b=TGdpaQFcQLK3oVKLxLQbUaRs4NWHvluy0aVATUJKdePw3xXDZWqp19BSChMH9y0uPa Agn2XwaNCpB+1HmiXlKGO1Rdi6NjQrFij3n5lpQiaYZunLwjD7vmLnsRgTWFoI3S8ZhE 2KLrpoZVK9poPvOZHHJ4QjgNOcu86P+krzoAa1r2dbALRzhleChIaBr3X2a1kgVH7GBC DhIvOsiYmQabQVQ+yca6lNIdN7jHTXLopMMtErbHGDFCGLk9DdfP7Pms6H5eKq471KeY LUR/sthd9/xL7UZQa/zBKHaApMQVzORil47//yVXk3ObHnWdLxoQCfe49XSXzyOTaz+m mgDA==
X-Gm-Message-State: ALyK8tJjz/4oPNjbLy0xUIDoCoR2JB3Bg3mDR561hoRZoHtOVSpuvZtjKYxHTCLYBZXgqT5YPMHWV1mAHJgArA==
X-Received: by with SMTP id v13mr185447ywa.152.1467888277704; Thu, 07 Jul 2016 03:44:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 7 Jul 2016 03:44:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Hugo Krawczyk <>
Date: Thu, 07 Jul 2016 06:44:08 -0400
X-Google-Sender-Auth: iw30-_f2-Z6wnxaJRrUAbDDWi9c
Message-ID: <>
To: Karthikeyan Bhargavan <>
Content-Type: multipart/alternative; boundary="001a114dd09e5cd9400537095ffe"
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: Thu, 07 Jul 2016 10:44:43 -0000

I do not have an objection to option 1 if re-phrased as
Option 1 - use the same key for protecting both *post*-handshake and
applications messages..

I believe this is what was intended by that option anyway. Let me clarify.

I understand the question as relating *only* to post-handshake messages and
to the main handshake (three initial flights). For the latter we have key
separation in the sense that none of these main-handshake messages is
under the application key but rather under dedicated handshake keys. This
not be changed as it provides key indistinguishability to the application
key, a
desirable design and analysis (=proof) modularity property.

On the other hand, for post-handshake messages, and particularly for
post-handshake client authentication messages, preserving key
indistinguishability is not relevant since at the time of post-handshake
client authentication, the application key has already lost its
by the mere fact that the key was used to encrypt application data. Key
indistinguishability is the main reason to insist in key separation and this
principle does not apply here anymore hence removing the objection to 1.

I'd note that the best one could hope for in the post-handshake setting is
as a result of post-handshake client authentication the application key
a secure mutually-authenticated key for providing "secure channels"
As pointed out by others in previous posts I have an analysis showing that
delayed mutual authentication guarantee is achieved even if one uses the
application key to encrypt the post-handshake messages. I have circulated a
preliminary version of the  paper among cryptographers working on TLS 1.3
and  I will post a public copy next week so this can be scrutinized further.


On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <> wrote:

> If we are left with 1 or 3, the miTLS team would prefer 1.
> On the cryptographic side, Hugo has a recent (draft) paper that seems to
> provide
> some more justification for (1), at least for client authentication.
> I know this is a bit off-topic, but the miTLS team would also like to get
> rid of 0-RTT ClientFinished
> if that is the only message left in the 0-RTT encrypted handshake flight.
> That should remove
> another Handshake/Data key separation from the protocol, leaving only 3
> keys: 0-RTT data,
> 1-RTT handshake, and 1-RTT data.
> Best,
> -Karthik
> On 07 Jul 2016, at 02:49, David Benjamin <> wrote:
> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <> wrote:
>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <>
>> wrote:
>>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
>>> > I'm also curious which post-handshake messages are the problem. If we
>>> were
>>> > to rename "post-handshake handshake messages" to "post-handshake bonus
>>> > messages" with a distinct bonus_message record type, where would there
>>> > still be an issue? (Alerts and application data share keys and this
>>> seems
>>> > to have been fine.)
>>> Recasting all the post-handshake handshake messages as not something
>>> named "handshake" does make a degree of sense, on its own. (bikeshedding:
>>> I'd name it something more descriptive like "secondary negotiation"
>>> messages or something, though.) Even if this doesn't directly help with the
>>> issue at hand here, does forking these into a new ContentType sound like a
>>> useful move, in general?
>> I'm not sure what this would accomplish.
> Me neither. To clarify, I mention this not as a suggestion, but to
> motivate asking about the type of message. If the only reason the proofs
> want them in the handshake bucket rather than the application data bucket
> is that they say "handshake" in them then, sure, let's do an
> inconsequential re-spelling and move on from this problem.
> But presumably something about the messages motivate this key separation
> issue and I'd like to know what they are.
> David
> _______________________________________________
> TLS mailing list
> _______________________________________________
> TLS mailing list