IETF Logo Mail Archive

Re: [TLS] Refactoring client auth/re-key

Martin Thomson <martin.thomson@gmail.com> Sun, 19 October 2014 17:15 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1591A19E7 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 10:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 Gbj4q7I1EKAR for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 10:15:45 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F28F1A19E4 for <tls@ietf.org>; Sun, 19 Oct 2014 10:15:44 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id gi9so2781405lab.21 for <tls@ietf.org>; Sun, 19 Oct 2014 10:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dGgpIdv3AZlXA8H+xFT4TtFJ1tq61POrzTjmkR615hg=; b=ABQd7ZLva/A6Uzj4HoAagE6KTybP4/G3YR/YcVOVYWzdlXrESsFPBNp+U0f+E+9hMt 2SIoguYzKBD0NJVt4FF+BkCPadcyTBdmJBdUPmvgBF/A1iXt16Kj0DAVzpN/Zk+CJYcQ 3Dwe8loRutt7BeUE7tlRYQ6KWYII3SiuIqox7hwZHm1RFxRVdiuwrTPj/cvhkbHkw2PJ ERp0aGBS89UKkSwuo3uGyxr2v3kYlrARvhH+fXM61wK9OOck88k12uaYwMjHeojk9Vvh sCa2eOwpMTxnUDsH9NWhfbj7zMxzGevwi4T5s/jfgJKZjBbyC6XFq65c2GAqjCKH316H o9LQ==
MIME-Version: 1.0
X-Received: by 10.112.63.70 with SMTP id e6mr3543296lbs.93.1413738942765; Sun, 19 Oct 2014 10:15:42 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 10:15:42 -0700 (PDT)
In-Reply-To: <2D0BBEAE-F6D0-4D10-AFC5-5D9885CA48BB@inria.fr>
References: <CABcZeBOdpK_JEH4EwnsoTA8Rje5pS5CtSbFGh8rHQzse92m9Wg@mail.gmail.com> <CACsn0cmYs8TMeKcTvqxv1DUGizcp5k7uo86muoqYbGRH4xDQHA@mail.gmail.com> <CABcZeBMxw3Oz1U-6GeTAuUJ1bZbBYhRWsQgscrHFLcTHh=_H1g@mail.gmail.com> <94F22FB7-ACA4-407C-8528-E806DFA64F54@inria.fr> <20141019081551.GA12098@LK-Perkele-VII> <2D0BBEAE-F6D0-4D10-AFC5-5D9885CA48BB@inria.fr>
Date: Sun, 19 Oct 2014 10:15:42 -0700
Message-ID: <CABkgnnUboNyiL0nYBaeVL+gi0o6ugZviKkVMAP3CdGZReE-TDA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/thoQ52kfhxIPS3DRBgvTiFo3rKw
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Refactoring client auth/re-key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 19 Oct 2014 17:15:46 -0000

On 19 October 2014 02:58, Karthikeyan Bhargavan
<karthik.bhargavan@gmail.com> wrote:
> You’re right, including the peer identity applies mainly for non-PFS exchanges where
> the peer’s keycard is closely linked to its identity (RSA, PSK, and Fixed DH/ECDH)
> For DHE/ECDHE, if the client/server negotiate a known good group/curve, agreeing
> upon the DH params should be enough. Since, by default, the server can choose an
> arbitrary group, it seems prudent to include its identity.

I'm glad someone pointed that out; I've been meaning to.  The
session-hash draft talks about binding to identities, but that isn't
the important characteristic.

The important characteristic is that the master secret is bound to
information that can only be known to the communicating peers.  In the
non-ephemeral (legacy) mode, that means identity, but that's only
consequential.

Maybe this sentence needs to be revised:
   The Transport Layer Security (TLS) master secret is not
   cryptographically bound to important session parameters such as the
   client and server identities.

v2.27.8 | Report a Bug | By Email | System Status