On Sun, Oct 9, 2016 at 8:44 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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). > I think we would change that rule, probably. -Ekr > > > 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
