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

[Karthikeyan Bhargavan]

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  wrote:
> 
> On 26 August 2016 at 06:43, Sean Turner  wrote:
>> 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.
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On 26 August 2016 at 06:43, Sean Turner  wrote:
> 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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

Any more thoughts on these?

spt

> On Aug 03, 2016, at 09:59, Bauer Johannes (HOME/EFS) 
>  wrote:
> 
> 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)
> 
>o  When the handshake has completed, the server 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 server that supports renegotiation
>   needs to save the client_verify_data and server_verify_data values for 
>   future use.
> 
> 
> 
> Sect 4.3 (Server Considerations)
> 
>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.
> 
> 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
> 
> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bauer Johannes (HOME/EFS)]

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)

   o  When the handshake has completed, the server 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 server that supports renegotiation
  needs to save the client_verify_data and server_verify_data values for
  future use.



Sect 4.3 (Server Considerations)

   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.

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

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

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

[Benjamin Kaduk]

On 08/02/2016 09:32 AM, Bauer Johannes (HOME/EFS) wrote:
>
> 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 :-)
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bauer Johannes (HOME/EFS)]

Hi Watson,

On Tue, Aug 2, 2016 at 16:02, Watson Ladd wrote:
>> 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.

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

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

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

[Watson Ladd]

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