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

Watson Ladd <> Tue, 22 October 2013 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93A6211E8210 for <>; Tue, 22 Oct 2013 10:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tWbE3UdMSUbl for <>; Tue, 22 Oct 2013 10:52:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22c]) by (Postfix) with ESMTP id E32EC11E84D8 for <>; Tue, 22 Oct 2013 10:52:11 -0700 (PDT)
Received: by with SMTP id q58so8660964wes.3 for <>; Tue, 22 Oct 2013 10:52:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ydstNfc/JzS9T2vcP5cp/TpLEr3vQrQ9wqkwkVaDB50=; b=UzMQ0cA6j34Nu2+E3Z2TB3H1QiNSzSMXSzYHU7rYR+4GBtynroWFyInS0ZdeWZ8bnh sJhrpjILwi3INnwuuzv856FPZ4KYO+BwNg3uZTkt6J9EHp8lg/4i8R0/kv4YhHEkuoUY h9Ohi+yLI0zvj3KVQzFZXYsUpf+7fD8PGfkyesAgx2I3tnmUPUxcvwKnr1ey0y8Q0yF0 RF0Xb7dS4DZeHvVFpFLhYzgBVfln5kpCTczZE+nZ+3D6vn7R819qxjjZHRjk67JZc9xI 2r3yPI4zDDthg57VR+hnOJydP1AGM/HM5aarPfn15Uzj+f5ABblX63/lD0gHSzsj43Rn bDqw==
MIME-Version: 1.0
X-Received: by with SMTP id sd4mr3003593wjb.69.1382464331164; Tue, 22 Oct 2013 10:52:11 -0700 (PDT)
Received: by with HTTP; Tue, 22 Oct 2013 10:52:11 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 22 Oct 2013 10:52:11 -0700
Message-ID: <>
From: Watson Ladd <>
To: Adam Langley <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2013 17:52:24 -0000

On Tue, Oct 22, 2013 at 8:14 AM, Adam Langley <> wrote:
> On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd <> 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.
As a result disclosure of a ChannelID for a web server provides the
ability to falsely authenticate a connection.
>> 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?
Because of a stupid missing bit, you don't know which of two points
lead to the r value. If you did know this bit, you could
make the verification equation an identity in the curve and apply the
Bos-Coster trick Ed25519 does. I've not come up with
a way around this issue. Guess and check isn't worth it: it ends up
costing more than verifying one at a time.
> 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.
Fair enough: I assume P256 is performant enough for the applications
being imagined, but given
the constant kvetching about performance, I'm not sure everyone shares
that. (Then again, they
kvetch while using interpreted languages...)

The argument for batch signatures to reduce latency is as follows: so
long as connections are coming in at a rate slow enough for us to deal
with them, all is good. But when connections come in faster than we
can process, we can grind through the queue faster.

I personally think TLS 1.3 should use a client key and server key to
derive a forward-secure channel, and then carry out whatever proofs or
verifications (certificate presentations, etc) are required within it.
Done right this can be fast in latency and CPU terms. Done wrong we
have what we have now.
> 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.
Options have burned us in the past: there was a recent email
describing a case of deployments with incompatible cipher suites
to interesting results.
>> 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

Watson Ladd