Re: [TLS] Wrapping up cached info

[Marsh Ray <[e-mail]>]

On 5/17/2010 12:17 PM, Ben Laurie wrote:
> 
> Why is agility a problem, though - could we not say that any hash that is
> currently required as a signature hash can be used, and identify the hash in
> the extension message?

Sure we could, but is it worth the cost?

Client Hello and Server Hello offer one shot to negotiate the use of
caching and the identifiers being used. Having it also negotiate the
hash algorithm at the same time raises the difficulty a bit!

As I see it, here are some challenges raised by hash agility:

1. TLS implementations will have to implement all the schemes or risk
interoperability issues or at least missed caching opportunities.

2. Probably just one scheme will be used in practice anyway. It's likely
not to be the most secure of the defined choices. The other schemes may
get little testing.

3. Clients and servers will be required to maintain multiple hashes for
every cacheable object.

4. Clients will likely have to send multiple hash formats until it sees
what kinds the specific target server can work with.

5. The "cross-hashfn collision" attack must now be considered. E.g. a
preimage of one hash fn could collide with a value from another, unless
the algorithm id is somehow incorporated into the hash value itself.

6. Bad guy may be able to influence client and server to use his choice
of hash functions for caching. He could inject phony failures for
example. This could create a "weakest link" situation where the attacker
can choose the weakest hash function among all supported alternatives.

All in all, good clean fun. :-) I just don't want a reflexive "gotta
have agility" to make the proposal inelegant and unwieldy so it has
trouble gaining widespread acceptance.

- Marsh