Hi Two things that bothered me that I think have not been mentioned by either Mirja or David:
Section 2 says: "If the TLS handshake fails for non-cryptographic reasons … endpoints SHOULD behave as if the the TCP-TLS option was not present.” I’m missing what counts as “cryptographic” vs not. So there is one example: no matching ciphers, but we need a bit more: What about an unsupported public key on the server? What about an invalid signature? What about a bad Finished message? What about an unrecognized record type? An unrecognized handshake message? Second thing I’m missing is about how we get from the state of negotiating TLS to the state of behaving as if the TCP-TLS option was not present. Obviously with a fatal error (or “cryptographic reason”) the side that detected the failure closes the TCP connection. That’s the easy part. But what if we have a non-fatal (in the sense of tcpinc) issue? Does the detecting side send an alert? Does the other side begin transmitting plaintext immediately following the alert? Suppose the Client processes the Server’s ServerHello and is not happy (maybe there’s a missing extension). It sends an Alert, but the server is still sending the other messages (key share, How do we know at which point the server can abort sending records and start sending plaintext? I think the synchronization mechanism should be explained. HTH Yoav _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
