On Wed, Jul 27, 2016 at 6:11 AM Hubert Kario <hka...@redhat.com> wrote:
> 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 While we will indeed someday need to deal with that problem, it is still a ways out. Even with no intolerance of any kind, I do not expect any reasonable client to be willing to waste that much bandwidth on a key share that the vast majority of servers will not use. (HelloRetryRequest exists, so there is no need to predict all groups.) Checking numbers from Chrome, the overwhelming majority of today's ECDHE[*] servers select P-256, though one can expect X25519 to start coming up. (Google servers select it today, and I believe OpenSSL 1.1.0 is expected to as well. Probably others too.) With no prior knowledge, those two groups seem by far the most reasonable to send in an initial ClientHello. For reference, our in-progress TLS 1.3 implementation in Chrome does this with a 517-byte ClientHello, of which 186 bytes are the padding to bring it up to 5 + 512. With prior knowledge, of course, many things are possible. Perhaps a client will remember the group a server used last time (or use the ServerHello.supported_groups extension) and, if we believe the server prefers an unpredicted group, even if much much larger, predict that one. With prior knowledge, endpoint intolerance is less of a concern. I can imagine various unpleasant options should we need to balance predicting a widely-used large key share with intolerance, but by then any plans we make now will no longer be valid anyway. David [*] Negotiated FFDHE exists in TLS 1.3 and server-fiat DHE in TLS 1.2, but this irrelevant as those two are totally different animals anyway. All they have in common is the last three letters.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
