Yes, I agree that the problem is error handling. I get that it is trivial to distinguish encrypted from unencrypted, but I would appreciate it if the spec could clarify the appropriate actions in the scenario where an unencrypted (non-appdata) record is received after keys have been installed in the connection state. It would be strange to send an alert in response to an alert.
PS: I was testing with OpenSSL when I hit the interop issue. From: Martin Thomson <martin.thom...@gmail.com> Date: Wednesday, April 26, 2017 at 8:42 AM To: "m...@sap.com" <m...@sap.com> Cc: Ilari Liusvaara <ilariliusva...@welho.com>, Roelof Du Toit <roelof_dut...@symantec.com>, "tls@ietf.org" <tls@ietf.org> Subject: [EXT] Re: [TLS] Alert after sending ServerHello On 26 April 2017 at 22:25, Martin Rex <m...@sap.com<mailto:m...@sap.com>> wrote: The code I was talking about was handling the special case that the server might receive either encrypted or unencrypted alert in response to its flight. And the difference it makes is just what error is declared as abort reason. Up to TLSv1.2 there was no confusion about whether a TLS record was encrypted or not: everything before "ChangeCipherSpec" is cleartext, everything thereafter is encrypted. That's not a problem here either. It's trivial to tell between an encrypted record and an unencrypted one. The question - if there is any - is when to start encrypting if there happens to be an error.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
