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
- [TLS] Refactoring client auth/re-key Eric Rescorla
- Re: [TLS] Refactoring client auth/re-key Watson Ladd
- Re: [TLS] Refactoring client auth/re-key Eric Rescorla
- Re: [TLS] Refactoring client auth/re-key Ilari Liusvaara
- Re: [TLS] Refactoring client auth/re-key Manuel Pégourié-Gonnard
- Re: [TLS] Refactoring client auth/re-key Eric Rescorla
- Re: [TLS] Refactoring client auth/re-key Watson Ladd
- Re: [TLS] Refactoring client auth/re-key Karthikeyan Bhargavan
- Re: [TLS] Refactoring client auth/re-key Ilari Liusvaara
- Re: [TLS] Refactoring client auth/re-key Karthikeyan Bhargavan
- Re: [TLS] Refactoring client auth/re-key Martin Thomson
- Re: [TLS] Refactoring client auth/re-key Martin Thomson