Re: [TLS] AD review of /draft-ietf-tls-cached-info-20

[Dave Garrett <[e-mail]>]

On Monday, December 21, 2015 02:35:11 pm Hannes Tschofenig wrote:
> On 11/20/2015 03:16 PM, Stephen Farrell wrote:
> > - 2^16-1 CachedObject instances makes no sense at all, that would be
> > bigger than the full handshake. Why not pick a sensible value?  Even
> > if you don't put such a value in the syntax, you could at least say
> > that e.g. N instances will likely be pointless, for whatever N
> > (10-ish?) would make the h/w bigger overall.
> 
> That's indeed a bit large. I reduced it to 1..2^8-1.

You need to reduce the max size of hash_value by two now, too. Now that CachedInformation is a max of 255 bytes, hash_value+type has to be a max of 255, thus hash_value can have a max of 253 with CachedInformationType being one byte and the length of hash_value being another byte.

Reading the design in full, I think it might be a better idea to just set a fixed size for hash_value instead of using a variable size vector. Your design only relies on collision resistance of the hash and are truncating to 32-bit. I would simply set the hash_value size to a fixed 4 bytes and state that future hash algorithms used MUST NOT have a collision resistance worse than SHA256 when truncated to 4 bytes, which seems like a perfectly reasonable requirement to me. Switching to a fixed size structure has a few benefits:
1) Smaller, as you don't need to send lengths anymore.
2) Simpler to iterate through a client's CachedInformation if needed, as all entries are of the same size.
3) More clear spec, as the struct definition directly reflects how things are actually going to be used, rather than over generalizing.


Dave