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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 21 Dec 2015 20:35:11 +0100

Hi Stephen,

thanks for your review comments.

On 11/20/2015 03:16 PM, Stephen Farrell wrote:
> 
> Hiya,
> 
> I've requested IETF LC for this one. (Sorry for being slow
> getting to it.) Please treat my comments below along with
> any other last call comments.
> 
> - You probably thought about this but I forget the argument.
> Wouldn't it have been better to include the cached info that is not
> sent within the transcript? I can't see an attack myself, but then
> we didn't get the triple-handshake problem even after the initial
> double-handshake attack was known.

You are actually describing the problem we were having: We had both
versions throughout the history of the document. There is this feeling
that there could be an attack (somehow) but nobody knows how it works
and so it is hard to decide for one or the other approach.

> - ID nits complains that 6234 has obsoleted 4634, and indeed so it
> has:-) I'll note that in the LC announce.

Ok.

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

> 
> - page 6: wrt 7250 do you need to say that the server can tell which
> thing (cert or SPKI) the client has cached from the hash value? I
> think it can only work that way, but it might be worth saying that.
> If it works some other way, then I didn't get that, so probably some
> other bit of text would be needed.

I added a note. I do indeed assume that the server is able to select the
right certificate/SPKI from the received hash value.

> - typo: consideratios

Ok.

Ciao
Hannes

> 
> Cheers,
> S.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Dave Garrett <[email-masked]>
Date: Wed, 23 Dec 2015 14:54:35 -0500

> 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