Re: [TLS] Wrapping up cached info

[Ben Laurie <[e-mail]>]

On 17 May 2010 19:14, Marsh Ray <[e-mail]> wrote:

> 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!
>

I am not suggesting negotiation, I am suggesting a statement. Since the hash
is already required elsewhere in the protocol, there is no need to
negotiate.


> 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
>