That does seem like a good idea to include a client time stamp in the 0RTT
flow to let the server force 1RTT in the case where this is too far off as
this bounds the duration of the replay window. (I suspect we'll find a
whole range of other similar attacks using 0RTT.) An encrypted client
timest
On Fri, Mar 11, 2016 at 10:21 AM, Kyle Nekritz wrote:
> Note: it’s also useful for the server to know which edge cluster the early
> data was intended for, however this is already possible in the current
> draft. In ECDHE 0-RTT server configs can be segmented by cluster, and with
> tickets, the s
Hi Kyle,
In my talk at TRON, I was also concerned by potential attacks from allowing
unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
implement replay protection using a cache, but requiring clients to provide
a timestamp in the client random is a great idea. Perhaps this
Hi Kyle,
Clever attack. I don't think it would be unreasonable to put a low
granularity time stamp in the
ClientHello (and as you observe, if we just define it it can be done
backward compatibly)
or as you suggest, in an encrypted block. With that said, though couldn't
you
also just include the in
