Return-Path: 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 ; 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 ; 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 ; Wed, 6 Jul 2016 22:10:24 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a66so17188194wme.0 for ; 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 In-Reply-To: Date: Thu, 7 Jul 2016 07:10:20 +0200 Message-Id: <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com> References: <201607062024.46745.davemgarrett@gmail.com> To: David Benjamin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 05:10:26 -0000 --Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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.=20 I know this is a bit off-topic, but the miTLS team would also like to = get rid of 0-RTT ClientFinished=20 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.=20 Best, -Karthik > On 07 Jul 2016, at 02:49, David Benjamin = wrote: >=20 > 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.) >=20 > 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? >=20 > I'm not sure what this would accomplish. >=20 > 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. >=20 > But presumably something about the messages motivate this key = separation issue and I'd like to know what they are. >=20 > David > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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

= --Apple-Mail=_571035BB-6F52-4889-8A59-6F86BA566BD5--