On Tue, Aug 2, 2016 at 6:33 AM, Bauer Johannes (HOME/EFS) <johannes.ba...@bosch.com> wrote: > Dear mailing list, > > regarding RFC5746 (https://tools.ietf.org/rfc/rfc5746.txt) I do have a > question which could not be solved in our internal discussions. Therefore I > would kindly ask for your comments on my issue. If I posted to the wrong > place, please advise on where such a question would be relevant instead. > > The question revolves around TLS servers (and clients) which do not support > renegotiation at. The server side is the more interesting of the two, hence I > will discuss it first. Sect 4.3 says: > > In order to enable clients to probe, even servers that do not support > renegotiation MUST implement the minimal version of the extension > described in this document for initial handshakes, thus signaling > that they have been upgraded. > > This hint refers to Sect. 3.6 ("Server Behavior: Initial Handshake"). It says > that a server in any case (independent if it supports or does not support > renegotiation at all) must send a empty renegotiation_info TLS extension as > soon as it receives a client request for that info (be it either by a > renegotiation_info or by the SCSV). Sending that empty renegotiation_info is > really no problem even for deeply embedded TLS servers (the message is only 5 > bytes and always static). > > However, there is also this in Sect. 3.6 which has caused some confusion and > lengthy discussion among my colleagues and myself: > > o When the handshake has completed, the server needs to save the > client_verify_data and server_verify_data values for future use.
Yes, and since it doesn't read them out, it should use write only memory as an optimization. Sincerely, Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
