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

[Stephen Farrell <[e-mail]>]

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.