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

From: "Bauer Johannes (HOME/EFS)" <[email-masked]>
Date: Tue, 2 Aug 2016 13:33:20 +0000

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 | [email-masked]
Registergericht: Amtsgericht Stuttgart, HRB 754585;
Geschäftsführung: Dr. Peter Schnaebele, Veronika Danner

---

From: Watson Ladd <[email-masked]>
Date: Tue, 2 Aug 2016 07:02:54 -0700

>       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

---

From: "Bauer Johannes (HOME/EFS)" <[email-masked]>
Date: Tue, 2 Aug 2016 14:32:51 +0000

Hi Watson,

>memory as an optimization.

So I take it my interpretation is correct -- these values are only ever required for renegotiation and serve no other purpose? I.e. the hint can safely be ignored in this case and the implementation will still be fully RFC5746-compliant?

All joking aside, this has seriously led to some discussions where implementation of said RFC was rejected because of the overhead it might cause. And even among some people who write SSL stacks for a living.

So while, if the RFC is read correctly (it's "need", not "MUST"), this is obvious, it really is confusing in practice. Since wide adoption of this RFC is of interest to everyone, I think an official clarification might help tremendously. Even if it's really obvious for people who design TLS :-)

Cheers,
Johannes

--
Johannes Bauer

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Aug 2016 09:57:21 -0500

> So while, if the RFC is read correctly (it's "need", not "MUST"), this is obvious, it really is confusing in practice. Since wide adoption of this RFC is of interest to everyone, I think an officia…

The next step is for someone to write proposed text that would be more
clear.  Maybe you have thoughts about how things could change?

-Ben

---

From: "Bauer Johannes (HOME/EFS)" <[email-masked]>
Date: Wed, 3 Aug 2016 13:59:14 +0000

Hi Ben,

On Tue, Aug 2, 2016 at 17:05, Benjamin Kaduk wrote:
> The next step is for someone to write proposed text that would be more clear.
> Maybe you have thoughts about how things could change?

Sure, I can give it a shot. Below is my proposal. Curious to hear your
thoughts on it. I propose slight wording changes in three parts and a new
Sect. 4.6 which sums up what is to do for minimal implementations.

Cheers,
Johannes

Sect. 3.4 (Client Behavior: Initial Handshake)

   o  When the handshake has completed, the client needs to save the
      client_verify_data and server_verify_data values for future use.

could be clarified as follows:

   o  When the handshake has completed, a client that supports renegotiation
      needs to save the client_verify_data and server_verify_data values for
      future use.

Sect. 3.6 (Server Behavior: Initial Handshake)

could be clarified as follows:

   o  When the handshake has completed, a server that supports renegotiation
      needs to save the client_verify_data and server_verify_data values for
      future use.

Sect 4.3 (Server Considerations)

could be clarified as follows:

   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 do not suffer from an insecure renegotiation vulnerability.

New Sect 4.6 (Minimal Implementation)

   Signaling that insecure renegotiation is not supported is a useful effect
   of the adaptation of this RFC regardless of whether or not a specific
   implementation supports renegotation or not. Since minimal implementations
   typically do not support renegotation, they also are implicitly not
   vulnerable to the attacks described in the beginning of this document.

   Therefore it is sufficient for clients that do not support any kind of
   renegotation to simply include the TLS_EMPTY_RENEGOTIATION_INFO_SCSV
   signaling cipher suite value in the ClientHello, as described in Sect. 3.4.

   For TLS servers which do not support renegotiation, it is sufficient to
   parse ClientHello messages for either the
   TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite value or an empty
   renegotiation_info TLS extension. In either cases, the server MUST respond
   with an empty renegotation_info TLS extension, as described in Sect. 3.6.

   Neither servers nor clients which do not support renegotiation will
   therefore have the need to store additional variable data in memory during

   runtime.

--
Johannes Bauer

Robert Bosch Smart Home GmbH | Schockenriedstr. 17 | 70565 Stuttgart-Vaihingen | GERMANY | www.bosch-smarthome.com<http://www.bosch-smarthome.com>

---

From: Sean Turner <[email-masked]>
Date: Thu, 25 Aug 2016 16:43:03 -0400

Any more thoughts on these?

spt

> On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS) <[email-masked]> wrote:
> 
> Hi Ben,
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Sep 2016 01:21:53 +1000

> Any more thoughts on these?

I have no problem with implementations that don't use R-I (in either
extension or SCSV form) if they don't intend to ever renegotiate.  I
know that that disagrees with RFC 5746, but there you have it.

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Wed, 31 Aug 2016 12:25:47 -0400

Recall that the original renegotiation attack relied on a client that has no intention
to renegotiate but was still fooled into renegotiating the attackers’s connection to the server.
To prevent this attack, it is essential that the client includes an empty R-I in its client hello.
This negative acknowledgment is as useful as a positive one.

This is particularly true on the client side. A server that does not support renegotiation
may be able to get away with not supporting R-I, but this probably also leads to 
some (weak) attacks.

> On 31 Aug 2016, at 11:21, Martin Thomson <[email-masked]> wrote:
>