Re: [TLS] RFC5746: Renegotiation Indication for minimal servers

[Watson Ladd <[e-mail]>]

On Tue, Aug 2, 2016 at 6:33 AM, Bauer Johannes (HOME/EFS)
<[e-mail]> 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