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

Watson Ladd <watsonbladd@gmail.com> Sat, 18 October 2014 15:15 UTC

Return-Path: <watsonbladd@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 8D28D1A88AF for <tls@ietfa.amsl.com>; Sat, 18 Oct 2014 08:15:26 -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 cYpWnXArHvZY for <tls@ietfa.amsl.com>; Sat, 18 Oct 2014 08:15:25 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6A281A88A1 for <tls@ietf.org>; Sat, 18 Oct 2014 08:15:20 -0700 (PDT)
Received: by mail-yk0-f170.google.com with SMTP id 20so1094702yks.1 for <tls@ietf.org>; Sat, 18 Oct 2014 08:15:20 -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; bh=WQ1JVjRTpOjf4EMP8olZC3AJlE/Mk0Y568gi5NF4BRM=; b=Bpw3P3kt0x5CldA0WXMm4n12LxIWvC46z65OJg1oUc9ekHq94Qup6YPaaXGqw6SHIm JbNFuEVysBwmgOw+mKz28qaTetxlCsf5SH6EZUMt2ExWHi41ptngAut0oriOpunnF3Qu +4iRO/0/cECGa+ih0eyaqHERqytMFdzbUzaTjjumqjCKan9jy8I6DBi7AXrPnMO9a3xK 7OkgiLb8c4OfZVqkmwNbeyg5dQpOdRwl7ucmC9DlUVmLwkUh0T4Ob3L/uBqDsKgCB/Tz mjGS2YP9yni0KTaqTL7J0WmNoDo2h2zlrOxsFoYlhvYwZ1M47iWkCuzHiuEu+VA9XYpj NJ1g==
MIME-Version: 1.0
X-Received: by 10.236.61.6 with SMTP id v6mr21738187yhc.44.1413645320051; Sat, 18 Oct 2014 08:15:20 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sat, 18 Oct 2014 08:15:19 -0700 (PDT)
In-Reply-To: <CABcZeBOdpK_JEH4EwnsoTA8Rje5pS5CtSbFGh8rHQzse92m9Wg@mail.gmail.com>
References: <CABcZeBOdpK_JEH4EwnsoTA8Rje5pS5CtSbFGh8rHQzse92m9Wg@mail.gmail.com>
Date: Sat, 18 Oct 2014 08:15:19 -0700
Message-ID: <CACsn0cmYs8TMeKcTvqxv1DUGizcp5k7uo86muoqYbGRH4xDQHA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2kxA0IG4G9q6vCkYPsvJoYKHVf4
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: Sat, 18 Oct 2014 15:15:27 -0000

On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
So I seem to remember DJB telling me that once you have a properly
made channel via Diffie-Hellman, that authenticating requires just
signing a value derived from the key. (Sadly I forgot/don't know the
proof, so someone will have to check this or tell me I'm completely
wrong) So we don't need the session hash to include the certificates,
and so don't need to keep the running hash going past the first
exchange.

Concretely the idea would be as follows: A sends to B g^x, and B
responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
need to hash the actual messages.)

At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
channel keys can be used to encrypt each side as in the proposal, and
the authstrs can be signed and sent over the channel to provide a
proof of identity. Furthermore, we could extract a channel binding in
an analogous manner, or application level keys in the same way, or a
resumption key in the same way.

Because we run the rest of the exchange over an encrypted,
authenticated channel, message manipulation isn't as much of an issue,
so the updates don't need to include the hashes they do above.

This seems to me to remove a lot of complexity in your proposal,
without affecting security. It also gets closer to generic security:
any authentication mechanism that uses a fresh value can use
A_authstr. Any means of providing a secure channel with a shared
string can use the keys, etc.

Sincerely,
Watson Ladd