On Sun, Oct 09, 2016 at 07:10:59AM -0700, Eric Rescorla wrote: > On Sun, Oct 9, 2016 at 6:58 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote: > > > After the discussion on PR #615, I took another pass at this with some > > > help from the research community. Please see: > > > > > > https://github.com/tlswg/tls13-spec/pull/672 > > > > > > > Also, an observation: This seems to interact in somewhat annoying way > > with stateless HRR. > > > > Basically, CH reconstruction no longer works properly, so one needs to > > have a freezeable PRF hash (and most implementations of hashes can not > > be frozen). > > > > I've been coming to the conclusion that CH reconstruction is a bad idea. > It's > tricky to get right and in the common case involves a lot of bloat in the CH > (because of duplicating the Key Shares). I think we would be better off just > removing it and replacing (rather than appending to ) KeyShares in HRR. > This was primarily intended as an attempt to avoid the need to continue > the hash in any case. >
That creates a bit of a edge case, where the server might need to pull client's share accross retry. (Since if group is OK, the group is not included in HRR, which presumably causes the client to blank its KeyShare). Also, doing some size calculations: ClientHello with "smallest group" rule is ~200 bytes with reasonable parameters (I got a dump of one TLS 1.3 draft-16 CH from my TLS stack, it is 265 bytes, but would be 196 with "smallest group" rule). The amount of space needed to freeze (octet) SHA-256 is 32+63+8=103 octets. And the space needed to freeze (octet) SHA-384 is 64+127+16=207 bytes (for full SHA-256 and SHA-384, add one more byte). So if selecting ciphersuite using SHA-384, the state size might be comparable to ClientHello size. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
