IETF Logo Mail Archive

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

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Thu, 07 July 2016 05:10 UTC

Return-Path: <karthik.bhargavan@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 7E8CD12B006 for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 22:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 2SktxTObTRFS for <tls@ietfa.amsl.com>; Wed, 6 Jul 2016 22:10:25 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 B347012D0E7 for <tls@ietf.org>; Wed, 6 Jul 2016 22:10:24 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id a66so17188194wme.0 for <tls@ietf.org>; Wed, 06 Jul 2016 22:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=puDRR3vUOmg04/oR9suMAgyX8iL1wo503YuRCBaJ0LU=; b=1FAWl3VbJtoB1cWhqxj21JsIy51u4PeI4eN73tpPtQWUtnSOdO2EzTYfRPgAmE2DpF ChSOK3H1fq6n+vqN/AQD4aVrfMQ0JdztuhgoMl8HDXtbvf0851QBfSOiueyUPLQAenO1 b68makl5Ew+RAEMmhzYiyF11X1rukLPHaiyLknZhsTFxA444P+slR+5cwOWPJMIpuCFT 3NMQlvbHj1n7P/plIjtaKd2E13e1L8LFswaxqtHu5IU6Zf4w2N5n3qsORwFtFRH2kzzx smW2gaeYwdznsQWNJSQyftQn9AOBUEtK9Xft25ckcjqeBU+NdLlehRjFYJTvCCcUrXi4 /Biw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=puDRR3vUOmg04/oR9suMAgyX8iL1wo503YuRCBaJ0LU=; b=ULnqQWUmInpQw5RA8vJboJyeP5YcX4NwDzCOYta3Pg0mFvTSLTonct0jGWhKFhFtY8 eYaCWxhlz3kl2uIYavVcVL6dZqnicM0QSDxTGmHXyDVJCLM7pDHBkOlJ/JRLOQPeDYi0 /3mqEdcWpeMvixrVF5AZET8h+qbxdZv6MJ0cDl7kROOtejqkfmGBQ+z9BTe7P9N5dQMW l53QN2obCUpCYdX5xTQa6YFzgBvNATDutxYZ4cy85bFh1dTwT1v10M+TWP2sKqOZDK2g 2PVY/T/RHscFJF5a1FpcI/91NFkn6WICmTRJeZ8Miuc84pggOSY6vJkraSuKpPoIv1qk CE/w==
X-Gm-Message-State: ALyK8tJ6Xh4YoM+vn25nd/wyViOHfTUxE71ckxC3/LHwv+vK+J8ktTeNnmLm6wFUU+AvWQ==
X-Received: by 10.194.220.234 with SMTP id pz10mr14182049wjc.142.1467868223175; Wed, 06 Jul 2016 22:10:23 -0700 (PDT)
Received: from macbook-pro.local (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id r127sm1125902wmf.21.2016.07.06.22.10.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jul 2016 22:10:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <CAF8qwaArt-kmRf3EBdo4j7Q-xFEe25LZLperxzqtKqV-2sbJ1Q@mail.gmail.com>
Date: Thu, 07 Jul 2016 07:10:20 +0200
Message-Id: <4809BB22-BF00-4824-93BD-2C66497CC557@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>
To: David Benjamin <davidben@chromium.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tDRn4w9KaWSAf6SvYzEwXStW1gM>
Cc: "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: Thu, 07 Jul 2016 05:10:26 -0000

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 <mailto:ekr@rtfm.com>> wrote:
> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.com <mailto: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

v2.23.0 | Report a Bug | By Email