Re: [TLS] New cached-info draft 09 posted

[Marsh Ray <[e-mail]>]

On 07/13/2010 10:44 AM, Martin Rex wrote:
> Marsh Ray wrote:
>
> I do not see a convincing argument to cripple this extension to TLSv1.2,

I agree. This could save lots of overhead in the right circumstances.

> Spelling it out for all three existing TLS protocol versions might
> avoid confusions and incorrect conclusions.
> for TLSv1.0&  TLSv1.1 use SHA-1, for TLSv1.2 use SHA-256.

Yes, a valid example never hurts.

>> To me, the PRF seems simpler because it's consistently defined in each
>> TLS version.
>
> How come?

PRF("cached info", "cached info", <as defined for Finished>)
       [0..object_hash_length - 1];

Hard to get much simpler. And it already exists in everyone's 
implementation!

>         P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
>                                HMAC_hash(secret, A(2) + seed) +
 >
> There is neither a secret nor a seed involved in the cache identifier,

Where that "seed" it's just meaning the third input parameter to PRF().

True there is no secret key for the MAC, this is inherent in the usage.

> and we also do not need an arbitrary length output, so the PRF() looks
> like a square peg to a round hole.

It's not a perfect match, but neither is SHA-1. In order to match TLS 
1.0-1.1, we need (SHA-1||MD5). Compared to 36 bytes of lousy hash, that 
arbitrary length output looks pretty good.

> When used for caching
> it is sufficient when the client learns the hash algorithm to use
> on receipt of the ServerHello handshake message that creates
> the cache entry.

If "the server" proposed that you cache some object using MD5 as the 
identifier, would you want your client to accept it?

TLS 1.0 doesn't use bare SHA-1 anywhere (except where it's due to some 
certificate limitations). So the choice comes down to unkeyed PRF, or 
SHA-256.

Personally, I'd go with SHA-256. I suggested it earlier, but it did not 
get a very enthusiastic response.

- Marsh