IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Sun, 19 October 2014 17:09 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 92E461A00C6 for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 10:09:35 -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 qDOpawg57mRI for <tls@ietfa.amsl.com>; Sun, 19 Oct 2014 10:09:33 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E791A19E4 for <tls@ietf.org>; Sun, 19 Oct 2014 10:09:32 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id 10so2798339lbg.18 for <tls@ietf.org>; Sun, 19 Oct 2014 10:09:31 -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=sX4C6jAXdJeFv2+H2xt1Qoer4F6FOeZALAdSBz/AqKw=; b=CgqAv4LYvK2NGYo2Lwg1D2zsvrthAu7d8oef/TR692dht4j+qjWeydHH9RL3ajeOSL k3PGzZYaZvDMt6m4TRtkqFdTlwSrBbZRafxj4tKlTrQexVmV2VfidjQ8bPkSNfO0X/gg VY2WdSOvpaJuyFU6iSkUsD6qM36VNHlY33yQ+/2RExJLYTIZ4aC9KPc7YDR4XaMBd/TO 5MI7mRnep3DHdbojfeMngDZVKZEGEHjpkZrsN9GxdF9qIiUfwuncihh6t7cibjz3xIX5 k6JurQbgcN0D13YhtcsZ/BxK7MSMBx7dCRuTiC6tx1TWkrFn4OMoUuXCeMJ7f2Prs2x0 YZ3w==
MIME-Version: 1.0
X-Received: by 10.112.63.70 with SMTP id e6mr3513160lbs.93.1413738571142; Sun, 19 Oct 2014 10:09:31 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Sun, 19 Oct 2014 10:09:31 -0700 (PDT)
In-Reply-To: <94F22FB7-ACA4-407C-8528-E806DFA64F54@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>
Date: Sun, 19 Oct 2014 10:09:31 -0700
Message-ID: <CABkgnnV5ZLQxGZw+-09kErPOrfRod+ati6Euh72U0y0_QXFj1g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XU06C-VdRft-tSFenUZSlQk2Jr4
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:09:35 -0000

On 18 October 2014 23:57, Karthikeyan Bhargavan
<karthikeyan.bhargavan@inria.fr> wrote:
> As Ilari hints, it is not enough to hash the client-server key shares into
> the master secret. In a negotiated protocol like TLS, we need to add
> the DH parameters, the algorithms used to derive the keys, and the
> algorithms that the resulting key will be used with. (The crypto proofs
> typically fix these values and so they don’t necessarily appear in the
> academic protocols.)

And it's not just that there are multiple options of algorithm.
Because there is choice involved, you need to include all the options
that were available.  Otherwise, clients are exposed to the
possibility of downgrade.

Hence the simplification of including the entire transcript still.

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