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. +49(711)81112906 | johannes.ba...@bosch.com
Registergericht: Amtsgericht Stuttgart, HRB 754585;
Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
