Re: [TLS] Data volume limits
On Monday 28 December 2015 21:08:10 Florian Weimer wrote: > On 12/21/2015 01:41 PM, Hubert Kario wrote: > > if the rekey doesn't allow the application to change authentication > > tokens (as it now stands), then rekey is much more secure than > > renegotiation was in TLS <= 1.2 > > You still have the added complexity that during rekey, you need to > temporarily switch from mere sending or receiving to at least > half-duplex interaction. this situation already happens in initial handshake so the implementation needs to support that I don't see how rekey adds complexity here... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 01/04/2016 12:59 PM, Hubert Kario wrote: > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: >> On 12/21/2015 01:41 PM, Hubert Kario wrote: >>> if the rekey doesn't allow the application to change authentication >>> tokens (as it now stands), then rekey is much more secure than >>> renegotiation was in TLS <= 1.2 >> >> You still have the added complexity that during rekey, you need to >> temporarily switch from mere sending or receiving to at least >> half-duplex interaction. > > this situation already happens in initial handshake so the > implementation needs to support that But after and the handshake and without real re-key, sending and receiving operations exactly match what the application requests. If you need to switch directions against the application's wishes, you end up with an API like OpenJDK's SSLEngine (or a callback variant which is equivalent in complexity). Dealing with this during the initial handshake is fine. But supporting direction-switching after that is *really* difficult. Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 12/28/2015 10:09 PM, Salz, Rich wrote: >> When the key is changed, the change procedure should involve new randomness. > > I don't think this is necessary, and I don't think the common crypto > expertise agrees with you, either. But I am not a cryptographer, maybe one of > the ones on this list can chime in. > > "Crank the KDF" suffices. The attacks against GCM are at the stage where even “periodically increment the key by one“ would thwart them, right? The risk is that without real re-key (introducing additional randomness), someone might come up with a better attack that reduces the security level below the design target, and which requires similar effort as the existing GCM attack (four years of traffic at terabit speed, it seems). Real re-key is difficult to introduce as an afterthought (see my recent response to Hubert), and I'd rather see such issues fixed at the cipher level if at all possible. The current update-key mechanism doesn't have the complexity issue of real re-key, but it's ambiguous if it's a design goal to paper over cipher deficiencies in the rest of the protocol. Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On Monday 04 January 2016 13:02:57 Florian Weimer wrote: > On 01/04/2016 12:59 PM, Hubert Kario wrote: > > On Monday 28 December 2015 21:08:10 Florian Weimer wrote: > >> On 12/21/2015 01:41 PM, Hubert Kario wrote: > >>> if the rekey doesn't allow the application to change > >>> authentication > >>> tokens (as it now stands), then rekey is much more secure than > >>> renegotiation was in TLS <= 1.2 > >> > >> You still have the added complexity that during rekey, you need to > >> temporarily switch from mere sending or receiving to at least > >> half-duplex interaction. > > > > this situation already happens in initial handshake so the > > implementation needs to support that > > But after and the handshake and without real re-key, sending and > receiving operations exactly match what the application requests. If > you need to switch directions against the application's wishes, you > end up with an API like OpenJDK's SSLEngine (or a callback variant > which is equivalent in complexity). for renegotiation, yes but for rekey it doesn't need any input from application so there is no need for any callbacks > Dealing with this during the initial handshake is fine. But > supporting direction-switching after that is *really* difficult. yes, this is a bit more problematic, especially for one-sided transfers. For example, when one side is just sending a multi-gigabyte transfer as a reply to a single command - there may be megabytes transferred before the other side reads our request for rekey and then our "CCS" message I thought you just meant the need to keep two cipher contexts in memory at the same time (current and currently negotiated). -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On 01/04/2016 01:19 PM, Hubert Kario wrote: >> Dealing with this during the initial handshake is fine. But >> supporting direction-switching after that is *really* difficult. > > yes, this is a bit more problematic, especially for one-sided transfers. > For example, when one side is just sending a multi-gigabyte transfer as > a reply to a single command - there may be megabytes transferred before > the other side reads our request for rekey and then our "CCS" message Yes, this is the issue I meant. I simply don't see a way to re-inject new randomness without a round-trip. (Key update without new randomness doesn't face this challenge, but then it's mostly cheating.) Florian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11
Hello All, Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. Section 5 of draft-ietf-tls-tls13-11 reads: "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." Then continues with: "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an "unexpected_message" alert." In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11
On Mon, Jan 4, 2016 at 7:45 AM, wrote: >> Hello All, >> >> Please excuse if this topic has been previously discussed. I have a >> question about TCP Keep Alives. >> >> Section 5 of draft-ietf-tls-tls13-11 reads: >> >> "Three protocols that use the TLS Record Protocol are described in this >> document: the TLS Handshake Protocol, the Alert Protocol, and the >> application data protocol." >> >> Then continues with: >> >> "Implementations MUST NOT send record types not defined in this document >> unless negotiated by some extension. If a TLS implementation receives an >> unexpected record type, it MUST send an >> "unexpected_message" alert." >> >> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT >> TLS Heartbeat). I take it that this will not work going forth? >TCP Keep Alive is invisible to the TLS connection. I see. Then, is it that PACKETS without the TLS record protocol may be sent on the TLS connection, but IF the TLS Record protocol IS used, then the record types must be one of those described? Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to TLS? > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11
On Mon, Jan 4, 2016 at 7:45 AM, wrote: > Hello All, > > Please excuse if this topic has been previously discussed. I have a question > about TCP Keep Alives. > > Section 5 of draft-ietf-tls-tls13-11 reads: > > "Three protocols that use the TLS Record Protocol are described in this > document: the TLS Handshake Protocol, the Alert Protocol, and the application > data protocol." > > Then continues with: > > "Implementations MUST NOT send record types not defined in this document > unless negotiated by some extension. If a TLS implementation receives an > unexpected record type, it MUST send an > "unexpected_message" alert." > > In the wild today, I see many TLS connections which use TCP Keep Alive (NOT > TLS Heartbeat). I take it that this will not work going forth? TCP Keep Alive is invisible to the TLS connection. > Thanks, > > Nalini Elkins > Inside Products, Inc. > www.insidethestack.com > (831) 659-8360 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11
TCP keep alives are handled by the TCP stack and not given to TLS or as Watson said invisible to TLS. Roland Am 04.01.2016 um 16:59 schrieb nalini.elk...@insidethestack.com: On Mon, Jan 4, 2016 at 7:45 AM, wrote: Hello All, Please excuse if this topic has been previously discussed. I have a question about TCP Keep Alives. Section 5 of draft-ietf-tls-tls13-11 reads: "Three protocols that use the TLS Record Protocol are described in this document: the TLS Handshake Protocol, the Alert Protocol, and the application data protocol." Then continues with: "Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST send an "unexpected_message" alert." In the wild today, I see many TLS connections which use TCP Keep Alive (NOT TLS Heartbeat). I take it that this will not work going forth? TCP Keep Alive is invisible to the TLS connection. I see. Then, is it that PACKETS without the TLS record protocol may be sent on the TLS connection, but IF the TLS Record protocol IS used, then the record types must be one of those described? Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to TLS? Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 ___ 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] TCP Keep Alive Question: draft-ietf-tls-tls13-11
Thank you all for your help. Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 - Original Message - From: Roland Zink To: tls@ietf.org Sent: Monday, January 4, 2016 8:32 AM Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11 TCP keep alives are handled by the TCP stack and not given to TLS or as Watson said invisible to TLS. Roland Am 04.01.2016 um 16:59 schrieb nalini.elk...@insidethestack.com: > > On Mon, Jan 4, 2016 at 7:45 AM, wrote: >>> Hello All, >>> >>> Please excuse if this topic has been previously discussed. I have a >>> question about TCP Keep Alives. >>> >>> Section 5 of draft-ietf-tls-tls13-11 reads: >>> >>> "Three protocols that use the TLS Record Protocol are described in this >>> document: the TLS Handshake Protocol, the Alert Protocol, and the >>> application data protocol." >>> >>> Then continues with: >>> >>> "Implementations MUST NOT send record types not defined in this document >>> unless negotiated by some extension. If a TLS implementation receives an >>> unexpected record type, it MUST send an >>> "unexpected_message" alert." >>> >>> In the wild today, I see many TLS connections which use TCP Keep Alive (NOT >>> TLS Heartbeat). I take it that this will not work going forth? >> TCP Keep Alive is invisible to the TLS connection. > I see. Then, is it that PACKETS without the TLS record protocol may be sent > on the TLS connection, but IF the TLS Record protocol IS used, then the > record types must be one of those described? > > Or is it that TCP Keep Alive is taken out by the TCP stack and not passed to > TLS? > > > >> Thanks, >> >> Nalini Elkins >> Inside Products, Inc. >> www.insidethestack.com >> (831) 659-8360 >> >> ___ >> 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > >> Similarly, in the HKDF-Expand-Label, do we assume a final null byte > >> for the "label"?> > > No. I wonder if we should instead add the '\0' explicitly in the > > 4.8.1 for maximal clarity. > Either that, or just remove the trailing 00 from the binary > description. the 0-byte is a C-ism that looks like a wart to me neither of the previous TLS versions used null-terminated C-style strings so why TLS1.3 should? Especially in just one place? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario wrote: > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null byte > > >> for the "label"?> > > > No. I wonder if we should instead add the '\0' explicitly in the > > > 4.8.1 for maximal clarity. > > Either that, or just remove the trailing 00 from the binary > > description. > > the 0-byte is a C-ism that looks like a wart to me > > neither of the previous TLS versions used null-terminated C-style > strings so why TLS1.3 should? Especially in just one place The idea is to make this prefix-free. I added it as an explicit byte but would be ok with a different separator as long as we banned it from the context strings. -Ekr > > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
> The idea is to make this prefix-free. I added it as an explicit byte but > would be ok with a different separator as long as we banned it from the > context strings. Perhaps explain that rationale in the doc? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On Monday 04 January 2016 09:44:57 Eric Rescorla wrote: > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario wrote: > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null > > > >> byte > > > >> for the "label"?> > > > > > > > > No. I wonder if we should instead add the '\0' explicitly in the > > > > 4.8.1 for maximal clarity. > > > > > > Either that, or just remove the trailing 00 from the binary > > > description. > > > > the 0-byte is a C-ism that looks like a wart to me > > > > neither of the previous TLS versions used null-terminated C-style > > strings so why TLS1.3 should? Especially in just one place > > The idea is to make this prefix-free. I added it as an explicit byte > but would > be ok with a different separator as long as we banned it from the > context strings. Calling it explicitly a separator would be less confusing. Advising implementers to check other values passed in for it and aborting if detected would be even better -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario wrote: > On Monday 04 January 2016 09:44:57 Eric Rescorla wrote: > > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario > wrote: > > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote: > > > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote: > > > > >> Similarly, in the HKDF-Expand-Label, do we assume a final null > > > > >> byte > > > > >> for the "label"?> > > > > > > > > > > No. I wonder if we should instead add the '\0' explicitly in the > > > > > 4.8.1 for maximal clarity. > > > > > > > > Either that, or just remove the trailing 00 from the binary > > > > description. > > > > > > the 0-byte is a C-ism that looks like a wart to me > > > > > > neither of the previous TLS versions used null-terminated C-style > > > strings so why TLS1.3 should? Especially in just one place > > > > The idea is to make this prefix-free. I added it as an explicit byte > > but would > > be ok with a different separator as long as we banned it from the > > context strings. > > Calling it explicitly a separator would be less confusing. > Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing "Following that padding is a context string used to disambiguate signatures for different purposes. The context string will be specified whenever a digitally-signed element is used. A single 0 byte is appended to the context to act as a separator." Advising implementers to check other values passed in for it and > aborting if detected would be even better > This seems like it's probably not necessary because these strings are standardized and internal to the implementation. -Ekr > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On 5 January 2016 at 05:03, Eric Rescorla wrote: > Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing > > "Following that padding is a context string used to disambiguate signatures > for different purposes. > The context string will be specified whenever a digitally-signed element is > used. A single 0 byte is > appended to the context to act as a separator." You call this NUL in the following paragraph, without context. This might need to be tied together better. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A small detail in HMAC key generation for Finished message
On Mon, Jan 4, 2016 at 4:11 PM, Martin Thomson wrote: > On 5 January 2016 at 05:03, Eric Rescorla wrote: > > Ask and ye shall receive: > http://tlswg.github.io/tls13-spec/#digital-signing > > > > "Following that padding is a context string used to disambiguate > signatures > > for different purposes. > > The context string will be specified whenever a digitally-signed element > is > > used. A single 0 byte is > > appended to the context to act as a separator." > > > You call this NUL in the following paragraph, without context. This > might need to be tied together better. > Fixed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
