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

[Adam Langley <[e-mail]>]

On Tue, Oct 22, 2013 at 2:32 PM, Trevor Perrin <[e-mail]> wrote:
> 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.

I agree that HMAC would, of course, be much faster but I believe that
public/private is needed for some of the higher level capabilities:
http://www.browserauth.net/proof-key-federation-protocols


Cheers

AGL