Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

[Ilari Liusvaara <[e-mail]>]

On Tue, Aug 02, 2016 at 03:03:13PM +1000, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/issues/572
> 
> Discuss.

Yeah, noticed that when trying to implement stuff. I do not see any
point in sending Finished in that case. Not sending Finished would
also make implementations that don't support post-handshake auth
simpler.

Also, what exact base key does that Finished use? Client's current
traffic secret at the beginning of the Finished (the sequence of
traffic secrets is the same client and server, but the values may
be out of sync.)?


I also noticed the hash forking issue. Even if I personally
nowadays deal with forkable hashes (even to the point of implmenting
multitap via forking) that is the only place forking is done.

However, those hash constructs look different from the ones in
handshake (not just different base context), which means those would
likely have to be implemented separtedly, increasing implmentation
effort.

However, if one wanted to use extra hashing there, so construction is
both compatible with the in-handshake one and doesn't require forking,
one would need to be a bit careful to stay out of cryptographic roughs.
E.g. it might be necressary to pad the hash to multiple of hash input
blocksize (like how HMAC does such padding with the key).




-Ilari