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

[Watson Ladd <[e-mail]>]

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.
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
leading
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
>
> AGL

Sincerely,
Watson Ladd