On Sun, Oct 18, 2015 at 8:59 AM, Yoav Nir <[email protected]> wrote:
> 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. > Yeah, I am starting to think I was getting too clever here and it would be better to just say "tear down the connection" -Ekr > HTH > > Yoav > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
