On Thu, Jun 23, 2016 at 6:35 AM David Benjamin <david...@chromium.org> wrote:
> On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote: >> > When implementing 0-RTT, an in particular the ticket_age extension, we >> > discovered that this greatly increases the complexity of the server >> > state machine. >> > >> > David Benjamin rather flippantly described a solution to this problem: >> > XOR the ticket age value with something that is either derived from >> > the old session keys or was included in the NewSessionTicket message. >> > >> > I propose we take David's solution. After all, simple is better: >> > >> > https://github.com/tlswg/tls13-spec/pull/503 >> >> I don't see a warning that reusing a ticket with that scheme causes >> the "masking" to break (the classic "multiple time pad" broken scheme). >> > > Probably worth expanding on in the text, but the assumption here is that > EncryptedExtensions' only purpose in life was to defeat correlation. That > is, if we didn't care about that, we'd put it in the clear like other > ClientHello fields. (Which means integrity is provided by handshake > transcript, as with other ClientHello fields.) > > To that end, if you were reusing a ticket, you've already leaked a more > fun correlator (the ticket) and must not have cared about leaking the > ticket_age either. > I suppose there is a slight difference from ticket reuse in that ticket reuse correlates the resumption connections together but not the connection which minted the ticket. The ticket age helps you correlate that initial connection too. I don't think this matters. Just don't reuse tickets. But, if we cared, per the "dumbest possible thing that might work" school of thought, we can replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta between two ClientHellos, which, precision aside, was already public information from the receive time (with ticket as correlator). The timestamp of the ticket-minting connection is as secret as before. > If something more heavyweight is wanted, probably better to derive some > extra key off the session key material + stuff (ought to include > client_random if worried about ticket reuse) and toss it into the cipher's > AEAD or something. It didn't seem we needed any of it, so I "flippantly" > proposed the dumbest possible thing that might work. :-) > > David >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
