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] Keeping TLS extension points working

[David Benjamin]

To expand on that a little, since it seems comments (a) and (b) are really
the same one:

The purpose of having an explicitly reserved list (b) is precisely so we do
not have to do a second handshake (a). The purpose here is to ensure we
exercise the little-used codepaths, not introduce new ones. This is
intended to be an extremely minimal mechanism. Clients add a tiny bit of
code to their ClientHello and no server code changes at all. (Note that
every MUST in the document is just reiterating what TLS already requires.)

David

On Tue, Aug 2, 2016 at 9:47 AM Steven Valdez  wrote:

> a) It seems like if an implementation has updated to be able to handle a
> specific GREASE alert, it should be able to handle not sending an invalid
> cipher suite. In general, its probably cleaner for the connection to
> fatally shutdown and then restart if the server is behaving that poorly.
> Servers that are sending back non-existent ciphers are also potentially
> broken in other ways, and I don't know whether a client should trust that
> it can reset any handshake state correctly if it were to try doing a
> "warning" alert.
>
> b) The reasoning behind having an explicit list is so that implementations
> don't send a value that ends up being defined as some other valid value.
> Otherwise its possible that some implementations will update to include
> GREASE values, but they might not update immediately upon new values being
> assigned by IANA, which means that there will be periods of times that some
> clients might send "fake" values that collide with real values, confusing
> the peer implementation into believing they actually support something that
> they don't and resulting in more intolerance issues between outdated GREASE
> clients and newly updated servers, with this intolerance being firmly the
> GREASE clients fault. The hardcoded list gets around this by making sure
> GREASE never overlaps with an actual value, though at the trade-off that
> badly designed implementations could choose to just hard-code ignore the
> GREASE codepoints.
>
> On Tue, Aug 2, 2016 at 2:59 AM Raja ashok  wrote:
>
>> Hi Benjamin,
>>
>>
>>
>> I have gone through the GREASE mechanism which you proposed in your new
>> draft. It’s really a nice idea for finding a buggy server before it thrives.
>>
>>
>>
>> I am having few doubts on this, which are listed below.
>>
>> a)  What should be the behaviour of client incase if a buggy server
>> responded for a GREASE value ?
>>
>> -  Consider a client sends a GREASE cipher value at first place
>> and followed by valid cipher suites, in its client hello.
>>
>> -  If a buggy server selects that cipher then it will response
>> server hello with that GREASE cipher value. At this case if client sends
>> FATAL alert then both side TLS and TCP needs to be closed and client needs
>> to recreate a new TCP connection, and then restart TLS handshake without
>> GREASE cipher value.
>>
>> -  Instead of this we can make client to send warning alert
>> (with new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111)) and restart TLS
>> handshake by sending client hello again.
>>
>> -  If a server receives this new warning, then it should be
>> ready to receive new client hello to restart handshake.
>>
>>
>>
>> SERVER
>> CLIENT
>>
>> CH (GREASE Cipher value & Valid Cipher value)  -->
>>
>>
>> <---  SH (GREASE cipher value)
>>
>> Fatal alert>
>>
>> TCP (SYN)>
>>
>>
>> <
>> TCP(SYN ACK)
>>
>> TCP (ACK)>
>>
>> CH (Valid cipher
>> value)  --->
>>
>> Scenario 1 : Sending FATAL alert for server
>> selecting GREASE value
>>
>>
>>
>> SERVER
>> CLIENT
>>
>> CH (GREASE Cipher value & Valid Cipher value)  --->
>>
>>
>> <---  SH (GREASE cipher value)
>>
>> Warning alert >
>>
>> CH (Valid cipher
>> value)  --->
>>
>> Scenario 2 : Sending WARNING alert for server
>> selecting GREASE value
>>
>>
>>
>> -  I hope sending warning msg and restarting TLS handshake will
>> be efficient.
>>
>> -  TLS Server must notify the application, whenever it receives
>> a GREASE warning alert.
>>
>>
>>
>> b)  Why only few values are specified as GREASE value ? Basically
>> all value which are not specified by IANA should be considered as GREASE
>> value right ?
>>
>> -  Basically client should maintain the list of values (cipher
>> suite, extensions) specified by IANA. The range of values.
>>
>> -  For example IANA specified cipher suite values are
>> {{0x,0x005C}, {0x0060,0x006D}, {0x0084, 

[TLS] RFC5746: Renegotiation Indication for minimal servers

[Bauer Johannes (HOME/EFS)]

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

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

[Eric Rescorla]

On Tue, Aug 2, 2016 at 5:25 AM, Ilari Liusvaara 
wrote:

> On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote:
> > On 2 August 2016 at 17:48, Ilari Liusvaara 
> wrote:
> > > Also, what exact base key does that Finished use? Client's current
> > > traffic secret at the beginning of the Finished (the sequence of
> > > traffic secrets is the same client and server, but the values may
> > > be out of sync.)?
> >
> >
> > Presumably it's the traffic_secret_N that is active at the start of
> > the sequence of messages; also presumably, the sequence of messages
> > cannot be interrupted by something like a KeyUpdate.
>
> It can't be interrupted by KeyUpdate from client, but can be interrupted
> by KeyUpdate by server.
>

Not sure why that matters. Key Updates are unidirectional. I think it
clearly has to
be sender's.

-Ekr




> (Also, I think base key only appears in Finished).
>
>
> -Ilari
>
> ___
> 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] Post-handshake Finished when rejecting a CertificateRequest

[Ilari Liusvaara]

On Tue, Aug 02, 2016 at 08:40:08PM +1000, Martin Thomson wrote:
> On 2 August 2016 at 17:48, Ilari Liusvaara  wrote:
> > Also, what exact base key does that Finished use? Client's current
> > traffic secret at the beginning of the Finished (the sequence of
> > traffic secrets is the same client and server, but the values may
> > be out of sync.)?
> 
> 
> Presumably it's the traffic_secret_N that is active at the start of
> the sequence of messages; also presumably, the sequence of messages
> cannot be interrupted by something like a KeyUpdate.

It can't be interrupted by KeyUpdate from client, but can be interrupted
by KeyUpdate by server.

(Also, I think base key only appears in Finished).


-Ilari

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

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

[Martin Thomson]

On 2 August 2016 at 17:48, Ilari Liusvaara  wrote:
> Also, what exact base key does that Finished use? Client's current
> traffic secret at the beginning of the Finished (the sequence of
> traffic secrets is the same client and server, but the values may
> be out of sync.)?


Presumably it's the traffic_secret_N that is active at the start of
the sequence of messages; also presumably, the sequence of messages
cannot be interrupted by something like a KeyUpdate.

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

Re: [TLS] Post-handshake Finished when rejecting a CertificateRequest

[Ilari Liusvaara]

On Tue, Aug 02, 2016 at 03:03:13PM +1000, Martin Thomson wrote:
> https://github.com/tlswg/tls13-spec/issues/572
> 
> Discuss.

Yeah, noticed that when trying to implement stuff. I do not see any
point in sending Finished in that case. Not sending Finished would
also make implementations that don't support post-handshake auth
simpler.

Also, what exact base key does that Finished use? Client's current
traffic secret at the beginning of the Finished (the sequence of
traffic secrets is the same client and server, but the values may
be out of sync.)?


I also noticed the hash forking issue. Even if I personally
nowadays deal with forkable hashes (even to the point of implmenting
multitap via forking) that is the only place forking is done.

However, those hash constructs look different from the ones in
handshake (not just different base context), which means those would
likely have to be implemented separtedly, increasing implmentation
effort.

However, if one wanted to use extra hashing there, so construction is
both compatible with the in-handshake one and doesn't require forking,
one would need to be a bit careful to stay out of cryptographic roughs.
E.g. it might be necressary to pad the hash to multiple of hash input
blocksize (like how HMAC does such padding with the key).




-Ilari

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