On Oct 18, 2015 9:31 PM, "Yoav Nir" <[email protected]> wrote: > > > > On 19 Oct 2015, at 6:24 AM, Martin Thomson <[email protected]> wrote: > > I can't think of any situation in which a compliant, valid ServerHello > > would induce that behaviour. It would have to be busted somehow, I > > guess. > > I was thinking some extension missing from the ServerHello that the client isn’t willing to do without, but I can’t think of any that makes sense. A ServerKeyExchange might have a key or a signature that fails some standard. I guess the “western” client with the GOST server is solved by the server returning an alert instead of a ServerHello. In this case they could continue with the connection but it’s still a matter of classifying all the fatal vs non-fatal conditions. That and coming up with an alternate term that does not confuse with the fatal and non-fatal alerts of TLS.
My point was that there would be mandatory to use cipher suites for tcpinc, thereby eliminating that sort of error scenario. If you wanted to negotiate something else, like GOST, that would have to be mutually supported, otherwise you would always have a good fallback that should work. The handshake would never fall in that case, though it would be impossible to build an implementation that relied on "special" ciphers only (in other words, that would not be tcpinc and using the tcpusetls tcpeno option would not be valid for such an implementation).
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
