Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00

Trevor Perrin <trevp@trevp.net> Thu, 24 October 2013 01:40 UTC

Return-Path: <trevp@trevp.net>
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 E809A11E80DC for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 18:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcOaPiIfxKui for <tls@ietfa.amsl.com>; Wed, 23 Oct 2013 18:40:55 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4791F11E81A7 for <tls@ietf.org>; Wed, 23 Oct 2013 18:40:55 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id n12so1646751wgh.35 for <tls@ietf.org>; Wed, 23 Oct 2013 18:40:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BmERWkujDo1m0f/tikZ3ZTWDfp0l9IjI0bs5W/R6x48=; b=gtMtnooFFLpFeg6G5Sk4g6mOTohqnkcQo9tJ46EmD/Sw37uk2qjJ8CfZrU3PzWeRZp Ghhr3yg0aYeLZQJo24GsMXsTZ98UwsiStx/8NaD15K+lTpMZm1zXUjomZpeZFMdR2eIG KkLHXAREcD6ZhT+UsTuWHWKJrDVCLsWM76fux1fWUaXyX6mx7if0tQ3d9FWQrruanzuM ccGOW+GDp0Ikh4rTUW4GhJcvKg8uR7RyphEMAg1eMbw3M7Q8PzHTWdLLyZLfj6oEXkg9 IN33P13TmKpqmVpTdkP0UoC2DKwENxTyhn9mBHJviAQBPkoGDCzqeas98zqh1iANxMAp OrGw==
X-Gm-Message-State: ALoCoQkhjXR7HP1O3zK9lSAuP1/GuCls6EiWT8NOAoIICnzvz7EPu2drF7v8RQ2Bpif6ZvecNQBc
MIME-Version: 1.0
X-Received: by 10.180.9.139 with SMTP id z11mr4423824wia.22.1382578854243; Wed, 23 Oct 2013 18:40:54 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Wed, 23 Oct 2013 18:40:54 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <CAL9PXLy_o+sW7sur+8Gko=uq83LnYbMJuAnScV1PXytEttyCLQ@mail.gmail.com>
References: <CACsn0cnzTuyezaCj0AmxtV_-6a04TZeAJtbBovAUQQfy16ua7w@mail.gmail.com> <CAL9PXLxdAGK2E5577xHJGexQpEWwrbC_Y+otEQmWfv2pV211HQ@mail.gmail.com> <CACsn0c=4HHw3PfCsRxnuHf+Rca1GrOSi60OjJQ4qoJKGcP60Pw@mail.gmail.com> <CAGZ8ZG2vF5qK+qv5vQ+J5szFU_E0dTbCmbXLupCfaBZq+se3cg@mail.gmail.com> <CAL9PXLy_o+sW7sur+8Gko=uq83LnYbMJuAnScV1PXytEttyCLQ@mail.gmail.com>
Date: Wed, 23 Oct 2013 18:40:54 -0700
Message-ID: <CAGZ8ZG0eCSCy+PZozRYogctUFqdhb6N5wv8dX4EkVM9A7UrHbQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 24 Oct 2013 01:41:00 -0000

On Wed, Oct 23, 2013 at 8:25 AM, Adam Langley <agl@google.com>; wrote:
> On Tue, Oct 22, 2013 at 2:32 PM, Trevor Perrin <trevp@trevp.net>; wrote:
>>
>> I do think ChannelID needs to explain the value of storing private
>> keys in a "secure element" further, and why storing ECDSA private keys
>> is better than, say, HMAC keys.
>
> I agree that HMAC would, of course, be much faster but I believe that
> public/private is needed for some of the higher level capabilities:
> http://www.browserauth.net/proof-key-federation-protocols


For binding cookies to a browser you could get by with symmetric
crypto.  There's proposals from websec on this (eg "Smart Cookies"
[1]).

For binding a token sent from an IdP to an RP, I wonder if there might
be a symmetric-key analogue to "Proof-key federation":

AIUI, the goals are:
 1) IdP receives some sort of proof that the same browser sharing
channel key Ki with the IdP is also sharing channel key Kr with some
RP.
 - IdP signs an assertion that is only useable by a browser with channel key Kr.

"Proof-key federation"/ChannelID achieves this by:
 1) A Javascript API where a browser signs cross-certificates between
the ECDSA keys Ki and Kr
 2) The IdP refers to Kr in its signed assertion

Imagine instead if Ki and Kr were HMAC "cookie keys" associated with
smart cookies between the (browser, IdP) and (browser, RP).  A
javascript API could be used to produce the triple:
  (nonce, HMAC(Ki, nonce), HMAC(Kr, nonce))

The triple would be forwarded to the IdP who would check HMAC(Ki,
nonce), then include the triple in the signed assertion.  The RP would
check HMAC(Kr, nonce).  The assertion is thus only usable to a browser
that know Kr, and is only issued to a browser that knows Ki.

Anyways, dunno if this is better than ChannelID or if I'm missing
something (probably).  But I'd like to see more analysis of why
public-key was chosen for ChannelID, in light of computation costs.


Trevor

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01729.html