Re: [TLS] RFC5746: Renegotiation Indication for minimal servers
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
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
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
Re: [TLS] Keeping TLS extension points working
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, 0x00C5}, {0x00FF, 0x00FF} ….. >> }. This sh
[TLS] RFC5746: Renegotiation Indication for minimal servers
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
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
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
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
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