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

Watson Ladd <> Thu, 24 October 2013 19:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECDC311E8345 for <>; Thu, 24 Oct 2013 12:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.533
X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PXvU+ytuF0+t for <>; Thu, 24 Oct 2013 12:52:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::234]) by (Postfix) with ESMTP id DE75811E82F8 for <>; Thu, 24 Oct 2013 12:52:30 -0700 (PDT)
Received: by with SMTP id f12so2845138wgh.31 for <>; Thu, 24 Oct 2013 12:52:30 -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=3bzCavslP9F9VCmy66dtQ+KQEK8uKrgeH8tAIEWS20s=; b=E14cG7Q0xsy2VBUxLbV0vK73mJA6x3dr5vC7ypvmMdmcwNhrs+91HU65F8vBzXc5D9 HP5iJ0GkDVJx0wsYI5gFTIa8/A0/X5tVPui/pgouuAwr5FRXKf8W2l/I8p5t0H4a4oIr KbPFGGjjX/eq4+FBIImgcqS/S2YkDRUc8IUYSVnUrGHd2sv3I5IxefMcYVGu2NwEP7tf 3wtWJeJOGCNmutO9Mmc/tJVuFSJzdcChK0koiys+3SYoEoFhGosBQsIxhqqXvgyO8ejO Bcys2FbZ1o68Ms2f2ChtqeEvZjhssLEFTxjbBZXszIKauvjZPwgSVbA2AXsOterr4fC7 kVoA==
MIME-Version: 1.0
X-Received: by with SMTP id m13mr3684376wiw.10.1382644350151; Thu, 24 Oct 2013 12:52:30 -0700 (PDT)
Received: by with HTTP; Thu, 24 Oct 2013 12:52:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 24 Oct 2013 12:52:30 -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: Thu, 24 Oct 2013 19:52:32 -0000

On Wed, Oct 23, 2013 at 8:21 AM, Adam Langley <> wrote:
> On Tue, Oct 22, 2013 at 1:52 PM, Watson Ladd <> wrote:
>> 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.
> Certainly that's true. However, it limits the attacker to an online
> attack: closing the laptop etc stops them. That's a lot better than
> the current situation where cookie theft is a significant problem.
Nope: the attacker could provide their own ChannelID and force the
user to reauthenticate,
thus causing their secret key to be trusted.
They could disable ChannelID entirely and force fallback to cookies,
which they then steal.
Online attack cleans
out a bank account just as quickly as offline.

ChannelID provides a benefit only if the user interaction authorizing
access to the ID generator
can be secured from malware interference, in which case we could just
use a cookie there instead.
> Additionally, ChannelID can be extended to an "ignition key" model
> where connections need to reprove the presence of the ChannelID every
> $n minutes. (That might get the verification load to the point where
> batching is useful :)
Steal a resumption ticket and you have the same attacker issue for $n minutes.
>> There also is a replay attack: a signature of a static string provides
>> no liveness
> ChannelID signs the handshake which includes an nonce from the server.
Yes, I stand corrected on this point.
>> 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.
> I have not looked into batching ECDSA verifies but [1] seems quite
> clear that it's dealing with unmodified ECDSA signatures (paywalled
> I'm afraid, but the first two pages are free). They report a speedup
> of 2x for batches with multiple signers, which is roughly equal to the
> reported speedup for Ed25519 (273K -> 134K cycles).
> [1]
>> 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...)
> I am not terribly happy with the performance implications of ChannelID
> either, but we're still exploring our options.
> Cheers

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin