Does anyone object to this change? If not, I intend to merge it in this weekend.
-Ekr On Fri, Dec 18, 2015 at 7:47 AM, Cedric Fournet <four...@microsoft.com> wrote: > The surprise is that breaking one key also yields the ability to truncate > traffic protected with another key. We agree that we don't have any > particularly scary way to exploit it against the current draft, but we'd > much prefer handshake encryption not to depend on 0RTT, and application > data protection not to depend on handshake encryption. > > With our proposed change, the main point to keep in mind is that, by > design, the TLS 1.3 record layer does not prevent suffix truncations. > Instead, TLS prevents prefix truncations at the protocol layer, by sending > an unambiguous final message with each record key: end_of_early_data; > finished; and close_notify. > > -----Original Message----- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: 17 December 2015 23:39 > To: Cedric Fournet <four...@microsoft.com> > Cc: tls@ietf.org; Antoine Delignat-Lavaud <an...@microsoft.com>; > Karthikeyan Bhargavan <karthik.bharga...@gmail.com> > Subject: 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 <four...@microsoft.com> > wrote: > > > > We propose to revert this change (that is, to reset the sequence > > number each time a new key is installed, as in TLS 1.2). If the > > chaining is still required for some other reason, one could instead > > include the old sequence number in the new key derivation (or the new > > key's additional data, but we believe this is no longer an option). > > Even with my question above, this seems reasonable to me. I'll note that > chaining in the way you describe would require that the rekey message (the > last message of the previous epoch) would need to be retransmitted in > DTLS. That seems more brittle, but we probably want to retransmit anyway, > since that would let use remove the explicit epoch from DTLS packets. > _______________________________________________ > 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
