Re: [TLS] Limiting replay time frame of 0-RTT data

[Martin Thomson <[e-mail]>]

I assume that you would run a tight tolerance on the 0RTT resumption by
saving the client's clock error in the ticket.  That a way only clients
with bad drift get no 0RTT. To do that all sessions need time.

I do not see how the server can do this in general without client help. But
the solution also addresses Brian's concern. The client doesn't need
absolute time, just relative time: How long since the ticket was issued.
Then it's an addition to the psk_identity only.
On 13 Mar 2016 1:49 PM, "Erik Nygren" <[e-mail]> wrote:

> 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
> timestamp could presumably be probed by the server.  (ie, if the server
> response is a different size for timestamp-expired vs timestamp-not-expired
> an attacker could keep probing until they change?)  That does seem like
> more effort, however.
>
>            Erik
>
>
> On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla <[e-mail]> wrote:
>
>> 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 information in the HTTP header for HTTP? Do you
>> think this is a sufficiently
>> general issue that it merits a change to TLS.
>>
>> -Ekr
>>
>>
>> On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz <[e-mail]> wrote:
>>
>>> Similar to the earlier discussion on 0.5-RTT data, I’m concerned with
>>> the long term ability to replay captured 0-RTT early data, and the attack
>>> vectors that it opens up. For example, take a GET request for an image to a
>>> CDN. This is a request that seems completely idempotent, and that
>>> applications will surely want to send as 0-RTT data. However, this request
>>> can result in a few things happening:
>>>     1) Resource unavailable
>>>     2) Resource cached locally at edge cluster
>>>     3) Cache miss, resource must be fetched from origin data center
>>> #1 can easily be differentiated by the length of the 0.5-RTT response
>>> data, allowing an attacker to determine when a resource has been
>>> deleted/modified. #2 and #3 can also be easily differentiated by the timing
>>> of the response. This opens up the following attack: if an attacker knows a
>>> client has requested a resource X_i in the attacker-known set {X_1, X_2,
>>> ..., X_n}, an attacker can do the following:
>>>     1) wait for the CDN cache to be evicted
>>>     2) request {X_1, X_2, …, X_(n/2)} to warm the cache
>>>     3) replay the captured client early data (the request for X_i)
>>>     4) determine, based on the timing of the response, whether it
>>> resulted in a cache hit or miss
>>>     5) repeat with set {X_1, X_2, …, X_(n/2)} or {X_(n/2 + 1), X_(n/2 +
>>> 2), …, X_n} depending on the result
>>> This particular binary search example is a little contrived and requires
>>> that no-one else is requesting any resource in the set, however I think it
>>> is representative of a significant new attack vector that allowing
>>> long-term replay of captured early data will open up, even if 0-RTT is only
>>> used for seemingly simple requests without TLS client authentication. This
>>> is a much different threat than very short-term replay, which is already
>>> somewhat possible on any TLS protocol if clients retry failed requests.
>>>
>>> Given this, I think it is worth attempting to limit the time frame that
>>> captured early data is useful to an attacker. This obviously doesn’t
>>> prevent replay, but it can mitigate a lot of attacks that long-term replay
>>> would open up. This can be done by including a client time stamp along with
>>> early data, so that servers can choose to either ignore the early data, or
>>> to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. This
>>> cuts down the time from days (until the server config/session ticket key is
>>> rotated) to minutes or seconds.
>>>
>>> Including the client time also makes a client random strike register
>>> possible without requiring an unreasonably large amount of server-side
>>> state.
>>>
>>> I am aware that client time had previously been removed from the client
>>> random, primarily due to fingerprinting concerns, however these concerns
>>> can be mitigated by
>>> 1) clients can choose to not include their time (or to include a random
>>> time), with only the risk of their .5-RTT data being delayed
>>> 2) placing the time stamp in an encrypted extension, so that it is not
>>> visible to eavesdroppers
>>>
>>>
>>> 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 server can store cluster information in the opaque
>>> ticket.
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>