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

Watson Ladd <watsonbladd@gmail.com> Tue, 22 October 2013 01:11 UTC

Return-Path: <watsonbladd@gmail.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 DB30A11E81A4 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 18:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 GK2h7XAy5zK0 for <tls@ietfa.amsl.com>; Mon, 21 Oct 2013 18:11:19 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A468011E82DE for <tls@ietf.org>; Mon, 21 Oct 2013 18:11:14 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id b13so5317259wgh.4 for <tls@ietf.org>; Mon, 21 Oct 2013 18:11:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DQTHfppB3Ewlqhd0z+Hf86V56G448LP9VSvfVkCNsAE=; b=Fn+n3skg6qstHqw0ZVEyG02CwOLWo6x5halWGt1RRxk8v9zGQpkkk7Dy1T4wsE/6Ag WyLo7K6BX53xyaDUKGmXDROfN0j+3LlGTwgXNv0/ybjNnkTPeeajM4OJnADsgFMOxfu2 cjZCI5J2EUQBEE9OcUuH1s6pgno9KySEhkHAM8ZI7qwJuJCrtbw0YpNQFctpV07MUP/K H8Cbt5jLKAYSRFfG25m6DyuBJbaWMPm+Iyax90DVw4AYYPyNR8WFa8H+Ntry+G0FckC3 Ly6OrZKAwCO/ptstMV4dLnH9Vs3x1wRYSCuIz/3/vpgBOn1WhQdfFXriVBsVZae8Eq0S x/OQ==
MIME-Version: 1.0
X-Received: by 10.180.72.237 with SMTP id g13mr12342387wiv.0.1382404273592; Mon, 21 Oct 2013 18:11:13 -0700 (PDT)
Received: by 10.194.242.131 with HTTP; Mon, 21 Oct 2013 18:11:13 -0700 (PDT)
Date: Mon, 21 Oct 2013 18:11:13 -0700
Message-ID: <CACsn0cnzTuyezaCj0AmxtV_-6a04TZeAJtbBovAUQQfy16ua7w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [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 01:11:20 -0000

Channel ID requires 2 modular exponentiations every handshake on the
server, even when sessions are resumed. The claimed argument for this
necessity is that resumption tickets could get stolen from the client.
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?

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.

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?
Sincerely,
Watson Ladd