[TLS] RFC5746: Renegotiation Indication for minimal servers

["Bauer Johannes (HOME/EFS)" <[e-mail]>]

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.

This is something that, in my opinion, only applies to servers who do support renegotiation. Those which do not support renegotiation at all are exempt from that requirement. Note that it also is not a hard ("MUST") requirement, but merely informative ("needs"). At least that is my interpretation.

For deeply embedded systems, we try to save every byte of RAM -- therefore, we really would like minimal support for RFC5746 (i.e. signal that our server will never use insecure renegotation so the clients are satisfied). However, we would also not want to persist any session-relevant data in RAM (more so because it doesn't make sense to save them without renegotiation capability in the first place). However, we really like clarification if we're reading the RFC correctly in this instance.

If we're indeed reading the RFC correctly, could we maybe try to get an additional clarification in as an erratum to make this unambiguous?

Thank you very much for your time,
Cheers,
Johannes

--
Johannes Bauer

Engineering Field Services (HOME/EFS)
Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihingen | GERMANY | www.bosch-smarthome.com
Tel. [phone] | [e-mail]
Registergericht: Amtsgericht Stuttgart, HRB 754585;
Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner