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

Trevor Perrin <trevp@trevp.net> Tue, 22 October 2013 18:32 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 AE2A811E8178 for <tls@ietfa.amsl.com>; Tue, 22 Oct 2013 11:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7EqP67qs+XiW for <tls@ietfa.amsl.com>; Tue, 22 Oct 2013 11:32:50 -0700 (PDT)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id AB43611E8137 for <tls@ietf.org>; Tue, 22 Oct 2013 11:32:49 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id x12so8212899wgg.4 for <tls@ietf.org>; Tue, 22 Oct 2013 11:32:48 -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=hKrPR/wmH6kLZ+7/8aNkpPyUXSONiaR3ML1ywGCQ/a8=; b=TuEVmHv67DY08iAL67n7i7nnRyeVlpN56o0knWynMZ26LwKgHB8Izqp14Rr7aXoUHb JE9EdbImhMWQ2iiDIYnFn2VEtNRGXiOo5ka971HRXr2tvOkbYFIyln/8satA4vd6ifgF G0xHTISZogBm8qsw4/irVy2/RwO7sA/WWci3kuf4NcGXbaZHYyLhE72CHpiMGHPCglOf 3d2AJM/5dLlvqpvie5LE/6pKnRtAFNDS1y9F72ZxeSJOXd8QVaxkDGe40DlUxlep0Dgp PPwWCM1R4x8fA8miS+U1rfQ4/Me60tCQfrTDk4r/OQEdfzQGANqJLtXOxrakpFT2N7JQ SrNg==
X-Gm-Message-State: ALoCoQnsmmeFzkCkyI2Ngd9bPIjcegqTCgEnQZlowJk/VTZWM3rDA/ZRCb6aylBgo89PX9zoPvah
MIME-Version: 1.0
X-Received: by 10.180.160.165 with SMTP id xl5mr15641736wib.48.1382466768838; Tue, 22 Oct 2013 11:32:48 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 22 Oct 2013 11:32:48 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <CACsn0c=4HHw3PfCsRxnuHf+Rca1GrOSi60OjJQ4qoJKGcP60Pw@mail.gmail.com>
References: <CACsn0cnzTuyezaCj0AmxtV_-6a04TZeAJtbBovAUQQfy16ua7w@mail.gmail.com> <CAL9PXLxdAGK2E5577xHJGexQpEWwrbC_Y+otEQmWfv2pV211HQ@mail.gmail.com> <CACsn0c=4HHw3PfCsRxnuHf+Rca1GrOSi60OjJQ4qoJKGcP60Pw@mail.gmail.com>
Date: Tue, 22 Oct 2013 11:32:48 -0700
Message-ID: <CAGZ8ZG2vF5qK+qv5vQ+J5szFU_E0dTbCmbXLupCfaBZq+se3cg@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Watson Ladd <watsonbladd@gmail.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: Tue, 22 Oct 2013 18:32:57 -0000

On Tue, Oct 22, 2013 at 10:52 AM, Watson Ladd <watsonbladd@gmail.com>; wrote:
> On Tue, Oct 22, 2013 at 8:14 AM, Adam Langley <agl@google.com>; wrote:
>> On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd <watsonbladd@gmail.com>; wrote:
>>> Why could Channel ID identifiers not get stolen when the resumption
>>> tickets are? Is there a reasonable threat model in which a client so
>>> compromised as to lose resumption tickets has a meaningful benefit
>>> from Channel ID?
>>
>> Because ChannelIDs have a public and private part, the private part
>> can be much better protected. For example, by moving it out of the
>> browser process completely, even on standard machines, and even under
>> hardware-protection, where such capability exists.
> Completely spurious: hardware (or a separate process) does not know
> whether it is being asked to provide
> the ChannelID for a request that is genuine or one that the attacker
> provided after subverting the browser process.
> There also is a replay attack: a signature of a static string provides
> no liveness, contrary to assumptions made here.

Hi Watson,

I think you're misreading the draft: ChannelID signs hashes of
handshake messages, not a "static string".

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.


Trevor