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

Adam Langley <agl@google.com> Tue, 22 October 2013 15:14 UTC

Return-Path: <agl@google.com>
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 C081611E84A4 for <tls@ietfa.amsl.com>; Tue, 22 Oct 2013 08:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 0dkTClbwlVka for <tls@ietfa.amsl.com>; Tue, 22 Oct 2013 08:14:57 -0700 (PDT)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 964BF11E84D1 for <tls@ietf.org>; Tue, 22 Oct 2013 08:14:56 -0700 (PDT)
Received: by mail-vb0-f49.google.com with SMTP id w16so4985625vbb.8 for <tls@ietf.org>; Tue, 22 Oct 2013 08:14:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZTjvIICRK3v+acIO1/+OW/AC+y0zC+utObm3fiiFFno=; b=I5SxuKr2WkHDFQsc5Pl2jQqkApnSnfoLLdc83bmNWdOvVM7hzRcBuazyO910fWHYys zaku0udVEIpMxc951JfSazHRYkg+/tKPwT64mwfYfRw1c4isCBcRboFT3lD7EflKDqv9 JiAL+TclZS0WW5O1KFlOQKB5a+F3ZcDDmkP6RV/MAmozKW2BnLxS2boqRx0mYU46hPYn TJaDA+klaYfMlj4ynEGJ6zHThkx9H6pdtZb194/YHxErJwP5qxuavlCKAf8MY3vAURQ0 U/ObWIS3lJlOWdg7Zeb6KB/GaaewmbRRV1+ivZlnwv6RgilyU6QLqggSCVjocZgTsELN ZAtA==
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:from:date :message-id:subject:to:cc:content-type; bh=ZTjvIICRK3v+acIO1/+OW/AC+y0zC+utObm3fiiFFno=; b=IlL5cCdnD857jcbTEsQRpb2IrfGh4e/nqn+CFBQtVknhcVFpYGnCKwxwmm2ZC7PbBs AEQxW/TP1o4T1Mcc2S/8/05pr6l2cALZrn1I+7dIvKysvFnr/qMF3Ye9E0xnpW5ZEAmM +JNiQa98Fqb68OYmYt+CC6IWiuuW0zppbFCuKJF6FhxpnWIXiZJTcwkQXCdsz5YCaK+z aR03sd5WuXkpoPm4xNyJhT85lkEsbsrRy56mLt5MZRKqMTmRpyhr3fd0XblyfTwPNeJM 5wtN/Qc695gb9HvetS0Hhj4BdA6D1F9HD7HBGBY+VRuCHF1Fb8Tnf1lDbCytCNFjlXKn Agbw==
X-Gm-Message-State: ALoCoQm3I07XXeGMEp6+FveRPw0O9k4eksoJbRB9Gf2rWsHi80chT/0sso7CHElMvUK+fr91x5vSRiAE4lgCMn2U5axFoNbhMTHy1TAkcrpifcjEizE3vsTakiOX0jhHs2O+6Y1cvG/c7lLpUfPLKwj3DYjuP8DYhtpAonaJZupTq9YLNS9BqQ7WBKU76Rm4IwxMKpvlRbGt
X-Received: by 10.52.164.102 with SMTP id yp6mr13348861vdb.14.1382454887583; Tue, 22 Oct 2013 08:14:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Tue, 22 Oct 2013 08:14:27 -0700 (PDT)
In-Reply-To: <CACsn0cnzTuyezaCj0AmxtV_-6a04TZeAJtbBovAUQQfy16ua7w@mail.gmail.com>
References: <CACsn0cnzTuyezaCj0AmxtV_-6a04TZeAJtbBovAUQQfy16ua7w@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Tue, 22 Oct 2013 11:14:27 -0400
Message-ID: <CAL9PXLxdAGK2E5577xHJGexQpEWwrbC_Y+otEQmWfv2pV211HQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
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 15:14:58 -0000

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.

> Why P256 and ECDSA? These choices prevent batch verification on the
> server, increasing the workload significantly. They do not have major
> security advantages, or performance advantages over Ed25519.

Why can't one batch verify ECDSA signatures?

The major issue with batch verification is latency: in order to build
a batch one has to wait for enough ChannelID connections (64 for the
batch speeds advertised for Ed25519) to be in the handshake stage. But
for HTTPS, latency is very important and we can't delay connections
for that long in normal processing.

That's not to say that batch processing is useless in all situations,
but it not always applicable.

The goal of wanting to put the private key into hardware protection
also motivated the choice of signing primitive since we get what we're
given with hardware. I did come close to adding signature primitive
negotiation to ChannelID recently but, due to bugs in old F5
firmwares, we cannot currently afford any extra bytes in the
ClientHello until we have workarounds in place. It may still appear in
the future.

> When browsers implement Channel ID, what separations between different
> websites are required? Cross-site request forgery has long been the
> bane of web authentication technologies: does Channel ID provide
> additional benefits here?

Dirk deals with the higher levels of the stack, so I'll pass on that question.


Cheers

AGL