Re: [TLS] Data volume limits

On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > Therefore, I think we shouldn't add the rekeying mechanism as it is > unnecessary and it adds too much complexity. Any arbitrary limit for a TLS connection is almost guaranteed to cause problems in the future. We cannot predict whether 2^x

Re: [TLS] Data volume limits

> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote: > >> Therefore, I think we shouldn't add the rekeying mechanism as it is >> unnecessary and it adds too much complexity. > > Any arbitrary limit for a TLS connection is almo

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

On 17/12/15 14:58, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-cached-info-20: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this >

Re: [TLS] Explicit use of client and server random values

On 12/16/2015 04:28 PM, Dave Garrett wrote: On Wednesday, December 16, 2015 04:15:00 pm John Foley wrote: Thanks for answering my questions. Have you considered adding KAT values for the key derivation steps? This would be helpful to implementors. RFC5869 already has KAT values for HKDF-Extra

[TLS] Poly1305 vs GCM

Given the issues w/ gcm currently under discussion, and that poly1305 was originally proposed to use w/ aes, should tls recommend aes-poly1305 instead of aes-gcm for those who want to continue to use aes? Or does chacha-poly1305 not fall victim to the 2^36 attack not because of the aead but rather

Re: [TLS] Poly1305 vs GCM

On Thu, Dec 17, 2015 at 02:14:18PM -0500, James Cloos wrote: > Given the issues w/ gcm currently under discussion, and that poly1305 > was originally proposed to use w/ aes, should tls recommend aes-poly1305 > instead of aes-gcm for those who want to continue to use aes? > > Or does chacha-poly130

Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)

As explained below, we propose that the record-layer sequence numbers be reset to 0 whenever new keys are installed (as in TLS 1.2): https://github.com/tlswg/tls13-spec/pull/379 Cédric Fournet, on behalf of the miTLS team. While working on a formal model of the TLS 1.3 record layer, I bumped in

Re: [TLS] Explicit use of client and server random values

I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash. That is, handshake_hash = Hash( client random|| server random

Re: [TLS] Explicit use of client and server random values

On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk wrote: > I have mentioned this in private conversations but let me say this here: I > would prefer that the nonces be explicitly concatenated to the handshake > hash. That is, > > handshake_hash = Hash( > > client random

Re: [TLS] Explicit use of client and server random values

> Does anyone else object or feel it makes analysis harder? :) Oh yeah, like anyone's gonna disagree with Hugo that this makes the analysis harder :) Paging Watson ... :) -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___

Re: [TLS] Explicit use of client and server random values

> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk wrote: >> I have mentioned this in private conversations but let me say this here: I >> would prefer that the nonces be explicitly concatenated to the handshake >> hash…. > > This change doesn't make implementation or specification significantly m

Re: [TLS] Explicit use of client and server random values

> On Dec 17, 2015, at 12:11 PM, Eric Rescorla wrote: > > > > On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk > wrote: > I have mentioned this in private conversations but let me say this here: I > would prefer that the nonces be explicitly concatenated to the h

Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)

So the actual impact here is that an attacker who has compromised a key can introduce a gap. Aren't there other options available to such an attacker? Scarier options? On 18 December 2015 at 07:01, Cedric Fournet wrote: > > We propose to revert this change (that is, to reset the sequence > numb

[TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for draft-ietf-tls-cached-info-20: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https

[TLS] Ben Campbell's No Objection on draft-ietf-tls-cached-info-20: (with COMMENT)

Ben Campbell has entered the following ballot position for draft-ietf-tls-cached-info-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to h

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-cached-info-20: (with COMMENT)

On Thu, Dec 17, 2015 at 10:09 AM, Stephen Farrell wrote: > > > On 17/12/15 14:58, Kathleen Moriarty wrote: >> Kathleen Moriarty has entered the following ballot position for >> draft-ietf-tls-cached-info-20: Yes >> >> When responding, please keep the subject line intact and reply to all >> email a

Re: [TLS] Explicit use of client and server random values

On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg wrote: > > > On Dec 17, 2015, at 12:11 PM, Eric Rescorla wrote: > > > > On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk > wrote: > >> I have mentioned this in private conversations but let me say this here: >> I would prefer that the nonces be explic