> Unfortunately, there is no client message that solicits the NewSessionTicket. > The message can be sent spontaneously by a server at any time.
The time since the client hello was sent/received can still be used if it is stored after opening the connection. It's also important exactly where and when the server checks the timestamp. If the timestamp is solely checked upon receipt of the client hello, an attacker can slowly trickle replayed 0-RTT data to the server, which somewhat defeats the point of a very narrow replay window (with a 1 second window, the connection must be opened with 1 second, but the application data could actually get delivered minutes later). -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, March 29, 2016 7:37 PM To: Colm MacCárthaigh <c...@allcosts.net> Cc: tls@ietf.org Subject: Re: [TLS] Narrowing the replay window On 29 March 2016 at 22:32, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > In an offlist exchange with Martin, I suggested allowing finer > granularity than 1s, e.g. 1ms. I think that this is reasonable. This might allow for tighter tolerance for drift, which means less replay opportunity. On 30 March 2016 at 04:45, Kyle Nekritz <knekr...@fb.com> wrote: > I think this will better account for the round trip delay if the elapsed_time > is defined on the client as the time since the request for the session ticket > (in other words, the time since the client hello was sent). Unfortunately, there is no client message that solicits the NewSessionTicket. The message can be sent spontaneously by a server at any time. On 30 March 2016 at 05:49, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > Is this intended to be somehow compatible with off-band configurations? If an out of band configuration is used, then we would need a rule for establishing the time that elapsed_time starts from and new rules about tolerances. This isn't going to be compatible straight off. On 30 March 2016 at 06:53, Colm MacCárthaigh <c...@allcosts.net> wrote: > It's likely I'm misunderstanding, but I'll ask to clear it up. Does > this proposal imply that a 0RTT section can only be sent within a very > tight time limit of when the server provided a resumption > ticket/configuration? No. If we accept Stephen's suggestion and go to milliseconds (I will do that), then the maximum age of a ticket is just over 7 weeks. Much longer than the time we allow a resumption ticket to live. _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=I9v9EWiJOFgT_atsbsPa_psibxuW6GdsLVEjN1MLvfY&s=6lVaBATyEochJpNSfU-oBmPKNSil7MtIklKFbKqJfM8&e= _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
