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

Hugo Krawczyk <hugo@ee.technion.ac.il> Mon, 18 July 2016 15:56 UTC

Return-Path: <hugokraw@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 7996112DA15 for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 08:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.576
X-Spam-Level:
X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, 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 e-AT52BZQEyR for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 08:56:35 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 71ECD12DA19 for <tls@ietf.org>; Mon, 18 Jul 2016 08:56:31 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id i12so162549965ywa.1 for <tls@ietf.org>; Mon, 18 Jul 2016 08:56:31 -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:cc; bh=+2ZdVcGGdeiJWhmcqDXWj4uxEcZufNwNqsGxOBUi1EE=; b=JxgrgQna8CPfnqU67mGwMMMViiq9M+lrpy6xhCKSoRfVtYy0ZDwWdA5TQfcPBw9AkD bu2+Gq1rdVJUTnBxcOGYaMNVB4zX8/kiS+1WO5xKrZQZ3IGgd1yPD0k416AFVvkJ47WJ 03s1LavKu9L0GCN4VpIHWXYhNpw62ROYGrcVT6HP/Yy2hvxeCGIObJCMnMFwbFK1/bUI RQNh2n6Q3/crSFmBQgP/VXNJuDUSHVdaN9/obRE5rcFLKaM+qdIC2XEskPXM2FzXMmQX ec8j5shbkpPAY9qbAKBlrmh1PHAZ0UEBDCzqt+3211rBd53xME66+Mme+uwyu9aZRJig eVZg==
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:cc; bh=+2ZdVcGGdeiJWhmcqDXWj4uxEcZufNwNqsGxOBUi1EE=; b=ZGNSbsT3p5NUE64CyPhBcKbtRIgFhS/z/cdKIAWwNxMHhv9LtOjntjSPec+y9jKoRC iKTGtbdYri4POjy4MqVY1f0ws9K+WJ6S5jg8e+oFep2BlSnf9CezoPrap9meJiVfDeAC LBG0FS2XfFoIOlM6gqXLb1UbhRKc2qO+/7VrnHO5ScPXdKbTHT6p27nC5oyiMteUYXfQ d1jwHqqEGr+cfmp2fIxVUDXNvw8DbkEOxhiy7Zy4nw6sijcTvG1/zctUL5Ub9BBiG37k bWFHmZn6Y3ZeWSpi1gjc+sDBmbVHKmelFIdU5fp7X60wJVMsWHiXYY+9ffQZFPqZC4lz 4l2Q==
X-Gm-Message-State: ALyK8tLorm9ObEkf7AXF9KqLi+Xe0RAiSBakR7lsV1Dka3KDq1J+rTs3hciq4NML9mrBXmg8LlMfApmGDcgmNQ==
X-Received: by 10.129.135.5 with SMTP id x5mr24867108ywf.114.1468857390498; Mon, 18 Jul 2016 08:56:30 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.37.64.82 with HTTP; Mon, 18 Jul 2016 08:56:00 -0700 (PDT)
In-Reply-To: <CADi0yUPXXwdRNJfrP_HiL9-F-8fuqstTpBukWgtEMkpSnQnysg@mail.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>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Mon, 18 Jul 2016 11:56:00 -0400
X-Google-Sender-Auth: tLA_mcWTqlIU7ca1bH24ijTs4jI
Message-ID: <CADi0yUPmtDi6Xjs0OcY9z1tMgiha_fZuBK1O9XqBGuCSiyzgvQ@mail.gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a114f11c6fcb9980537eb0257
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/M-i9NYOMD6TrWV-lHoyy3axPJ_M>
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: Mon, 18 Jul 2016 15:56:37 -0000

On Thu, Jul 7, 2016 at 6:44 AM, 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.
>

​Here is the promised posted paper
http://eprint.iacr.org/2016/711
"
A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with
Applications to Client Authentication in TLS 1.3)
​"​

Its analysis of client authentication is relevant to the different modes of
TLS 1.3 and, in particular, to post-handshake authentication. As said
above, the results support the use of the application key to encrypt the
post-handshake messages, hence avoiding the need to use a dedicated key for
this and the consequent need for trial decryption (or related techniques).

Comments on and off list are welcome.

Hugo
​


>
> 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
>>
>>
>