On Tuesday, 26 July 2016 16:27:32 CEST Brian Smith wrote: > Hubert Kario <hka...@redhat.com> wrote: > > TLS 1.3 170 3.8742 > > TLS 1.4 183 4.1705 > > > > size e/1356 10 0.2279 > > size e/1356 c/1356 5 0.1139 > > size e/1356 c/1357 5 0.1139 > > size e/2046 1 0.0228 > > size e/2046 c/1979 1 0.0228 > > size e/2049 4 0.0912 > > size e/2049 c/1153 1 0.0228 > > size e/2049 c/2049 2 0.0456 > > size e/2049 c/2050 1 0.0228 > > size e/2053 1 0.0228 > > size e/2053 c/555 1 0.0228 > > When we consider the most reasonable (initial) ClientHello sizes, it > seems that the ClientHello version number intolerance is a much more > significant problem than size intolerance, if I'm understanding your > numbers correctly.
you've missed one more number: > > Of those, 45 (1.03%) could not be connected to (did not receive a Server > > Hello/.../Server Hello Done reply) with the "Very Compatible" client hello so while TLS1.3 intolerance it is a bigger problem, it's a bigger problem by a factor of two or three (depending what sizes you consider problematic), not by an order of magnitude And given that the "best"[1] key share for post quantum crypto now is 1824 bytes in size, going above 2048 byte for client hello's on first connect is not unreasonable. That is *if* rlwe with those parameters turns out to be good enough and we won't need something even larger. 1 - https://www.imperialviolet.org/2015/12/24/rlwe.html -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
