IETF Logo Mail Archive

Re: [TLS] Consensus call for keys used in handshake and data messages

Cas Cremers <cas.cremers@cs.ox.ac.uk> Tue, 14 June 2016 12:45 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 9E38112D61A for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 05:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, 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 H3Z2nny3TjCE for <tls@ietfa.amsl.com>; Tue, 14 Jun 2016 05:45:30 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 3101D12D5CC for <tls@ietf.org>; Tue, 14 Jun 2016 05:45:30 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id v199so119578020wmv.0 for <tls@ietf.org>; Tue, 14 Jun 2016 05:45:30 -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; bh=IBxqqVZYUDLXFWRjwcWWrt4AIs0Ld6HFdsorjD7qmDU=; b=B8mstItrAgzsr+qGe4EOea4sEDUT6+3xAyHRYIaq/I0t1N5e6e+EwTCJQ/xZ2IintD trhLABap4FP0VOSpTvcjL2x6g8kDs+Z5EK1BbYuZAbdPG7vx5YKJIAnmHWxFFhLiwfVp QBpA1ptH5xPk0kIFG+YxiabBwr36XN5BJCBdL5SYkA29b3Xpzt2EENkvaeDYrdhHYqNA TuCkdDz5tUNGWGAtkKCLxJHWagGb0dDtqsB90z5j/379UHRtteoHLsLkn2ZzGJFhHxNE kQ508L4ToL7ih7mdF8z4Jw/vJfi5gpZkrZAKPBPfs3DcUHPOmu5NVt2KhETwtJSfD1tE 3fhw==
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; bh=IBxqqVZYUDLXFWRjwcWWrt4AIs0Ld6HFdsorjD7qmDU=; b=FOP9xJxuvCDAQAMceGqE7yFvKidpsJiUlSu8oqbjeDibkm2lGCsKjLXqE/8S2dC1Jx 6208KRXk/s98nQVEDtnHGerNj6Vf5SzjCGySs2yaFTIZ17+A5/kixgeC8kGU3rilSsBh hUv6k7r9BemaHCBHuqWcvVTkPCBhS/xt0t+/sL8cEJTcVTOddpnNPh9q2cL8XsrNxChF 8AgmghbtrDs0n3ZYmEXigLp6yy2S7LdXhN97dGRIs9JqkAuPfH0Fmet8g5q3VVov1MuB tnX5YawRW70z8oN4Nsk4b067cAPjyd7KhdhpPEPkavgEQrg7y8BNN9uytFSUm2Yn3FOU fclA==
X-Gm-Message-State: ALyK8tIkPLYt+0bH+M8CLf+xGGdRsmVvufU9wGt33K9sSR/z+6ZIqSr7TIgB2f2DHi3Osy/cNBpZwSkOWvhSSg==
X-Received: by 10.194.150.130 with SMTP id ui2mr6124608wjb.11.1465908328731; Tue, 14 Jun 2016 05:45:28 -0700 (PDT)
MIME-Version: 1.0
Sender: cas.cremers@gmail.com
Received: by 10.28.46.18 with HTTP; Tue, 14 Jun 2016 05:45:08 -0700 (PDT)
In-Reply-To: <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org>
References: <CAOgPGoDRZdJN7DY10tDoEEidVkxeKabCcW_U3vQqaaH6x162gw@mail.gmail.com> <8760tc3kd0.fsf@alice.fifthhorseman.net> <764f87ac-92ee-c410-35ac-d4a2cf0e51ad@mehnert.org>
From: Cas Cremers <cas.cremers@cs.ox.ac.uk>
Date: Tue, 14 Jun 2016 13:45:08 +0100
X-Google-Sender-Auth: 2vWOay54G4F-lOa8YhQSNhpCtqs
Message-ID: <CABdrxL4BPAG_Obm=_FJBxFMawVKYpfV97-zsHFerqh1tzpVZrQ@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="089e0112beda3521ca05353c6162"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/A87AUw8-mc3mGtK8IeD8Z51npi0>
Subject: Re: [TLS] Consensus call for 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: Tue, 14 Jun 2016 12:45:32 -0000

It is not quite as simple as saying "(1) makes proofs more complicated"
since it depends on what you are trying to prove.

(1) makes some styles of standard AKE property proofs (key secrecy,
authentication) harder
(2) might make some privacy proofs harder

Given that the proof-effort has mostly focused on secrecy and
authentication properties, one can argue for (2).
However, some proof styles can still work out in (1), so it is not such a
clear choice.

Over time, I've changed my mind, and I now prefer (2) (since we don't have
full detail on any privacy proofs) as long as the content-type essentially
boils down to a single bit of information (which key we are using) and
nothing else.

FWIW,

Cas


On Tue, Jun 14, 2016 at 1:12 PM, Hannes Mehnert <hannes@mehnert.org> wrote:

> On 13/06/2016 21:27, Daniel Kahn Gillmor wrote:
> > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
> >> 1. Use the same key for handshake and application traffic (as in the
> >> current draft-13)
> >>
> >  > or
> >>
> >> 2. Restore a public content type and different keys
> >
> > Given this choice, i prefer (1).
>
> FWIW, I prefer (1) as well
>
>
> hannes
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email