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

[Trevor Perrin <[e-mail]>]

On Tue, Oct 22, 2013 at 10:52 AM, Watson Ladd <[e-mail]> wrote:
> On Tue, Oct 22, 2013 at 8:14 AM, Adam Langley <[e-mail]> wrote:
>> On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd <[e-mail]> 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