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. - ID nits complains that 6234 has obsoleted 4634, and indeed so it has:-) I'll note that in the LC announce. - 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. - 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. - typo: consideratios Cheers, S. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
