Hubert Kario <hka...@redhat.com> wrote: > 170 were detected as TLS 1.3 incompatible (3.9%) > 183 were detected as TLS 1.4 incompatible (4.2%) > 229 were detected as TLS 1.253 incompatible (5.22%) > > in the below excerpt (full list below, this is just entries that have at least > 4 servers with same behaviour), "e/<number>" means that it's the smallest size > of "Very Compatible" client hello extended through the padding extension that > causes its rejection by server, similarly "c/<number>" indicates smallest size > rejected by server when the client hello is made big through addition of > cipher suite IDs
> Cumulative distribution function for size intolerancies looks like this: > > size <c/512 12 0.2733 > size <c/1024 16 0.3644 > size <c/2048 33 0.7515 > size <c/4096 47 1.0704 > size <c/8192 47 1.0704 > size >=c/8192 4064 92.5529 This seems like a good indication that clients should limit the number of cipher suites in the client hello. > > size <e/512 0 0 > size <e/1024 0 0 > size <e/2048 11 0.2505 A finer-grained breakdown of sizes between 0-2048 bytes is a better area to focus on. I personally would try very hard to ensure my ClientHello fits comfortably in a single packet if at all possible, at least for a connection to a server that I don't have a session ticket (or equivalent) for. > 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. Cheers, Brian -- https://briansmith.org/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
