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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls