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

Cas Cremers <cas.cremers@cs.ox.ac.uk> Fri, 08 July 2016 08:33 UTC

Return-Path: <cas.cremers@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1161112B01B for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 01:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVswb2wqdHN5 for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 01:33:51 -0700 (PDT)
Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (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 25BDA1288B8 for <tls@ietf.org>; Fri, 8 Jul 2016 01:33:51 -0700 (PDT)
Received: by mail-qt0-x241.google.com with SMTP id f89so3874748qtd.0 for <tls@ietf.org>; Fri, 08 Jul 2016 01:33:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wnShyLI8xoOrlY/P7h4b64KA+HVqHArdgaaV8DQRiuI=; b=GcfNGPcEIKugfjTapctH1Eq7U5Feoi6derq8iV8DYIjYjneYBxijsYWUEbKlXcu6eW YvThW0MbMXUeQsTjXr+diOiYw149A0EZi/DUoTLuiRxp06520Hvadw0GN/ou+VcUERp6 jubnQygzyH/Jojc6qy5+vWJARtwbGhR3FmdMEh/wCYVrGOFpB7l4EO05WuYKdArNCRx6 TciO2EpDdWoacfUS3yz2wmPMpxloKmy0xjvzm8PlynGHZkZcE8Jyj7a4jXls9buLYE1D uPgh6qtqodqRWfGi524+ZFynK9H+SEgT6sKixlwPFgCLLnHO/RRWpBX53ohVfTsOqdvl 5sSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wnShyLI8xoOrlY/P7h4b64KA+HVqHArdgaaV8DQRiuI=; b=dioT3vqRXdN73b05TOt7RpU/wJI0YxZ1AnCmwl/QXIzUQdsK4FW6pUmFXBC2fRolc/ 2t076VsOY5zaghaX1T8eNf6fFzxIZEZbFzw/jChGfBfIn2HS84tJoFoOVBuTXQyGkEO5 B4ezhBUOyuqgSE2iE4LUotttN09zE1t6xRwnHZTE2K007Jy4Chjew6W26An0o1oCfgvM 6U0zxr8oTIuoAgtha5xvlBFhKgvQGfOudQ+nJIsFKR2cbC8A+5UzD1FNE9Gb0lTze/0t w12FRdFZbFpyefodquwx5kpueyvq58+2AOUr54j35xnWrTQ4TBpgTiAaE3iA+c0Gy5YG CWkw==
X-Gm-Message-State: ALyK8tKGMV840EBDlJ4wsY4oQXIcPWc/M1xJQuuqmaSwIRnaHCS7wQUsN+82K+rDLYw7CcHYNPMsNEMcUiIrcQ==
X-Received: by 10.194.158.41 with SMTP id wr9mr4056922wjb.25.1467966830106; Fri, 08 Jul 2016 01:33:50 -0700 (PDT)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.28.6.130 with HTTP; Fri, 8 Jul 2016 01:33:30 -0700 (PDT)
In-Reply-To: <CA6DA4EA-16CE-4FC9-8930-019CC5CAFDAB@gmail.com>
References: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com> <A2C29D69-FF97-4C16-941B-87C0022C6362@gmail.com> <CAF8qwaC+iXoJ_Z9xuB4UqR4-7EmXUmr2pRRcBDxtDP-eZ8LzAg@mail.gmail.com> <201607062024.46745.davemgarrett@gmail.com> <CABcZeBO_Nh_u+++wOqH68j3mNfkM3A+W+4ZR7-J0ciV0-4q1KA@mail.gmail.com> <CAF8qwaArt-kmRf3EBdo4j7Q-xFEe25LZLperxzqtKqV-2sbJ1Q@mail.gmail.com> <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> <CADi0yUPXXwdRNJfrP_HiL9-F-8fuqstTpBukWgtEMkpSnQnysg@mail.gmail.com> <CA6DA4EA-16CE-4FC9-8930-019CC5CAFDAB@gmail.com>
From: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Date: Fri, 08 Jul 2016 09:33:30 +0100
X-Google-Sender-Auth: UUaxO5EjnsWyoz4TaWWQdH2M-DU
Message-ID: <CABdrxL6OwoHF6fKf4jzJn19qWMe87KHD=SMTV3fHD7z8WpUOMg@mail.gmail.com>
To: Douglas Stebila <dstebila@gmail.com>
Content-Type: multipart/alternative; boundary="089e011826b2736fe505371ba96b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Xr89tKrqiScMx6erRBMqDFW1R0U>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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: Fri, 08 Jul 2016 08:33:55 -0000

Hi,

After several discussions (including the ones Douglas points out) I have
also come round to option 1 as the preferred way forward. For our symbolic
analysis in Tamarin it should not make a big difference anyway.

Best,

Cas


On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila <dstebila@gmail.com> wrote:

> With Hugo's analysis of the secure channel-like security afforded even
> when the application key is used to encrypt non-application data, and as
> Cédric pointed out to me the application key will be used to encrypt
> non-application data like certain alert messages; so I think option 1 is a
> reasonable choice, and option 3 would not recover the composability
> property we hoped it might.
>
> Douglas
>
>
> > On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
> wrote:
> >
> > 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 not
> > 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
> encrypted
> > under the application key but rather under dedicated handshake keys.
> This should
> > 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
> encrypting
> > 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
> indistinguishability
> > 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 that
> > as a result of post-handshake client authentication the application key
> becomes
> > a secure mutually-authenticated key for providing "secure channels"
> security.
> > As pointed out by others in previous posts I have an analysis showing
> that this
> > 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.
> >
> > Hugo
> >
> >
> > On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <
> karthik.bhargavan@gmail.com> 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 <davidben@chromium.org> wrote:
> >>
> >> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
> >> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.com>
> 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@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>