Anti replay #1005

ekr · 2017-05-04T21:12:03Z

No description provided.

ticket is associated with a different PSK. This provides somewhat increased security in cases where you have multiple PSKs for the same connection and one PSK is compromised. The motivation here is that in cases where the server maintains a session database rather than self-encrypted tickets, the server might delete tickets as they are used,. This change provides FS for connections which have been used, even if there are other outstanding tickets in the session cache associated with the same original connection.

Colm MacCarthaigh. Specifically: - Describe both one time tickets and client hello storage ("strike register") mechanisms and SHOULD-level require people to do them. - Provide a security considerations section describing the threats.

ekr · 2017-05-04T21:12:16Z

@colmmacc please review.

vdukhovni · 2017-05-04T21:25:18Z

draft-ietf-tls-tls13.md

+time. The server can determine its view of the age of the ticket by
+subtracting the the time the ticket was issued from the current
+time. If the client and server clocks were running at the same rate,
+the client's view of would be shorter than the actual time elapsed on


Something missing after client's view of...

oops "ticket_age"

enygren · 2017-05-04T21:41:33Z

draft-ietf-tls-tls13.md

+described in {{stateless-anti-replay}}.
+See {{replay-0rtt}} for more information on the limitations
+of these mechanisms.
+


Perhaps mention that clients and application protocols must assume in their security profile (and in-terms of what they are willing to send via 0-RTT) that servers are only implementing stateless-anti-replay? (When the "server" spans multiple clusters with non-trivial latency between them, stateless-anti-replay is the only one that works and it has the weakest guarantees.)

(This is mentioned below, but repeating it here as well may be worthwhile.)

It's also possible to use an instance of Client Hello Recording per cluster in a distributed setup, effectively reducing the # of possible replay for a "Large Number" to 1 per cluster.

Aren't the three alternatives in the SHOULD all equal?

Servers need not permit 0-RTT at all, but those which do SHOULD implement either Single-Use Tickets {{single-use-tickets}}, Client Hello Recording {{client-hello-recording}}, or the stateless mechanism described in {{stateless-anti-replay}}.

This is a WG decision ultimately, but IMO they are not. the first two clearly are stronger.

I'd go further: the third method doesn't work - it doesn't prevent replays. It permits thousands to billions of replays, depending on the amount of bandwidth and hosts available, and it doesn't mitigate several of the attacks. It should be taken out - it's insecure.

enygren · 2017-05-04T21:45:37Z

draft-ietf-tls-tls13.md

+this enables a variety of attacks via side channels such
+as cache timing or measuring the speed of cryptographic
+operations {{Mac17}}.
+


Perhaps say "idempotent and side-effect free" rather than just "idempotent"? DELETE and PUT are idempotent but do have side-effects and without additional application layer controls an attacker doing 0-RTT replay could reorder them.

+1 to side-effect free.

First of all, I would talk about "actions" rather than requests. The things that the server does in response to receiving 0-RTT are what will be exploited.

Side-effect free is useful, but forbidding that doesn't really cover it. In @enygren's example, the side effects are relevant, but the primary effect (creation/update of a resource vs. removal) is what we're really concerned with. The only way to ensure that this is perfectly safe is to use the "safe" definition in HTTP - that is the request does nothing but generate a response. And even then, it's rare that such a request is ever free from side effects or side channels.

This risks us defining something that is very HTTP-centric. I would prefer that we instead say that idempotency is desirable for the actions that the server takes, but that idempotency could be insufficient. That is more or less what the text here is getting at.

I rewrote this a bit, but note that I'm not sure that any anti-replay mechanism we have considered will handle this in the face of sufficient client and server complicity.

Consider the following case:

Client sends CH + Early data

Attacker injects SH + RST

Client retries with a fresh connection (and a fresh CH)

Server processes the data

Attacker replays CH + Early Data

Ugh

vdukhovni · 2017-05-04T21:46:17Z

draft-ietf-tls-tls13.md

+server nodes, it may be hard to achieve high rates of PSK and and
+0-RTT success when compared with self-encrypted tickets which do not
+require consistent server-side storage for basic functionality but
+only for 0-RTT anti-replay.


Perhaps replace but only for 0-RTT anti-replay with , but may require such storage for 0-RTT anti-replay or something else that makes the sense more clear.

There should probably be some more clarification that 0-RTT success and PSK success are partially independent, and that tickets can still be used for PSK even if the single-use property cannot be guaranteed; that is, PSK can succeed even in cases where 0-RTT must be rejected for safety. (Unless I misunderstand?)

enygren · 2017-05-04T21:53:47Z

draft-ietf-tls-tls13.md

+{{stateless-anti-replay}} only prevents replay outside the
+time window.
+
+


Add something like this which covers the fundamental requirement and responsibilities:

"The onus is on clients not to send messages in 0-RTT data which are not safe to have replayed and which they would not be willing to retry across multiple 1-RTT connections. The onus is on servers to protect themselves against attacks employing 0-RTT data replication."

(or "___ have responsibility to" instead of "the onus is on"?)

This is pretty obvious, but worth stating, I think.

Yeah, worth stating again. Maybe also that the application profile should tell the client to do so.

Added it to an earlier location

knekritz · 2017-05-04T22:07:58Z

draft-ietf-tls-tls13.md

+described in {{stateless-anti-replay}}.
+See {{replay-0rtt}} for more information on the limitations
+of these mechanisms.
+


It's also possible to use an instance of Client Hello Recording per cluster in a distributed setup, effectively reducing the # of possible replay for a "Large Number" to 1 per cluster.

knekritz · 2017-05-04T22:12:10Z

draft-ietf-tls-tls13.md

+
+2. If the ClientHello matches an existing ClientHello, then
+   abort the handshake using an "illegal_parameter" alert
+   (this should never happen in a functional system).


To make this more efficient implementations can use some hashing/bloom filter rather than storing the entire client hello. This will have false-positives, in which case zero RTT data should just be rejected, not the connection aborted.

Ahh hipster crypto to the rescue.

Efficient storage isn't so much the problem as global synchronization within reasonable time frames.

Sure the entire client hello can be stored, but why not do it more efficiently?

I don't think this state is global (ie one client hello cache per cluster).

knekritz · 2017-05-04T22:14:57Z

draft-ietf-tls-tls13.md

+   (this should never happen in a functional system).
+
+3. Otherwise, store the ClientHello during the window
+   and accept 0-RTT.


It might be wise to explicitly recommend storing the PSK binder rather than the entire ClientHello. This has the benefit of essentially being a compact token cryptographically tied to the 0-RTT key (also preventing someone from polluting the replace cache with random data).

If the ClientHello needs to be valid, then polluting the cache is as trivial as just creating new and different ClientHello values. In a way, the binder is just a way of having the other side calculate your hash for you.

Kyle is right that you need to validate the binder, because it changes the cost of polluting the cache to the cost of getting a new PSK (and you can use PSK-specific filtering to blacklist bad actors).

Maybe it's obvious to others, but we also can't use a hash of the packet because if the CH contains two PSKs, then the attacker can corrupt the second binder without detection and potentially pollute the cache. So, I think you want either CH.Random or the binder.

colmmacc

<8

colmmacc · 2017-05-04T21:45:22Z

draft-ietf-tls-tls13.md

+       target: https://github.com/tlswg/tls13-spec/issues/1001
+       author:
+       -
+         ins: C. MacCarthaigh


Technically it's "MacCárthaigh", but maybe RFCs have to be ascii. And now my first comment gets to be super vain! Oh man.

Correct, ASCII only. Feel free to supply some other flattening :)

We're almost able to put people's names in RFCs, but the road is a long one (for reasons that I won't burden you with).

Ah, the 8th fallacy of naming! (Not all names are representable in Unicode.) ((Number probably wrong; I made it up.))

colmmacc · 2017-05-04T21:47:03Z

draft-ietf-tls-tls13.md

+all 0-RTT data and for PSK usage when PSK is used without DH.
+
+Because this mechanism requires sharing the session database between
+server nodes, it may be hard to achieve high rates of PSK and and


Minor mistake: "and and"

"between server nodes in environments with multiple servers acting as endpoints for the same service"

colmmacc · 2017-05-04T21:50:34Z

draft-ietf-tls-tls13.md

+  this can be estimated by measuring the time between sending
+  the Finished message and receiving the first message in the
+  client's second flight, or potentially using information
+  from the operating system.


I think lines 3600 - 3604 are probably impractical. If folks do want to use STEK-encrypted tickets for global resumption, then the RTT to one location will be very different than another. Even absent that, RTTs can vary quite a lot for Mobile users. As an implementor, I'd just use a global tolerance value (like 500ms or something).

I think it would make more sense to just say the server should store one thing:

The time that the server generated the session ticket, offset by an estimate of the round trip time between client and server.

That also makes it more clear that only information in the ticket can be used for these calculations (any RTT information in the resumption handshake can not be trusted).

colmmacc · 2017-05-04T21:52:10Z

draft-ietf-tls-tls13.md

+client sent the ClientHello as:
+
+~~~~
+    creation time + (client's view - RTT estimate/2)


I don't think the division by two is necessary. The ticket gets delayed by half an RTT on the way to the client in the first place, and half an RTT on the way back to the server. So it nets out to one RTT of difference. Means we also needn't worry about any asymmetry between the two directions.

I thought that initially, but I believe that's wrong, because we're interested in the client's claimed sending time.

Consider the case where clocks are globally synchronized and we have a 200 ms RTT.

We send NST at 0

The client receives NST at 100ms

The client waits 1000ms and then sends CH (at 1100)

The server receives CH at 1200

Now, if the client had put the absolute time in CH, it would have been 1100, but it puts in relative time so that's 1000. When we add 1/2 RTT, we get 1100. If we were to add RTT, we would get 1200, which is wrong, because that's when the server got it.

This is different from below where we are interested in the mismatch.

Oh you're right! Wait a second, no. I'm still wrong. But you're not totally right either. If we want to get very pedantic about it (pedantic on a crypto spec? no!) , all we know is that the client is some portion of the RTT behind. We don't know that it's 1/2. The RTT might be asymmetric. Imagine it's 20ms server -> client, but 180ms client to server.

We send NST at 0

The client receives NST at 20ms

The client waits 1000ms and then sends CH (at 1020)

The server receives at 1200

Oh, totally. It's just the best we can do.

Remember that we're not trusting this value, we're just using it to have the best chance of getting the time within the window we are saving CH for.

Hmm... Well, we are sort of trusting this, because we are using it to distinguish between hard fail and forced 1-RTT. OTOH, the attacker can always force us into that posture by just delaying the packet until its out of window, so I don't think that it's an issue. But it might be easiest to just use "issue time + obfuscated ticket age"....

Sorry @ekr , the comments are so deep I got lost on which section we're in. I thought this was about the stateless anti-replay.

It may be that you always want to force 1-RTT and never hard-fail on detecting replays. There may be some legitimate scenarios to receive a replay. For example, TCP FastOpen (or QUIC) combined with 0RTT and packet duplication in the network. Hard-fail could result in some weird race conditions here. Having hard-fail (fatal alert, I assume?) as distinct from forcing 1-RTT could also just give an attacker more information.

TCP FO is still TCP - a duplicate packet will be rejected by the TCP state machine and shouldn't make it as far as TLS.

I tend to agree with Nygren about not giving the attacker more information -- that is, don't hard-fail and just fall back to 1-RTT [unless you're under attack and need to shed load]. The 1-RTT will fail for the attacker's replays, of course.

I'm persuaded by knekrit's argument

MT, cute trick, but it doesn't work if you want the window to be on arrival time, so only for the stateless technique, not strike registers.

enygren: I was more ambivalent about whether to abort in this round

colmmacc · 2017-05-04T23:03:40Z

draft-ietf-tls-tls13.md

+
+3. Otherwise, store the ClientHello during the window
+   and accept 0-RTT.
+


It might be adding something here ala ...

It is also critical to the sure that the record of ClientHellos that led to accepted 0-RTT sections from a given window is complete, before accepting any new 0-RTT sections for that same window. For example, if the system recording ClientHellos crashes with no durable record of the ClientHellos previously accepted, then the system needs to wait at least one full window before accepting any ClientHellos.

That's probably not going to fly. The window is large and waiting that long would kill all the benefits that 0-RTT provides. I would instead recognize that challenges exist in synchronizing state across participating nodes. See Erik Nygren's comments on the list that amount to basically "not gonna happen", which I agree with.

It's fine to recommend this design, but the need to have globally consistent state is a massive hurdle.

The window here is just the clock skew tolerance window (ie 10s of seconds). Waiting 1 window before starting to accept 0-RTT data sounds very reasonable to me.

I believe the intent of these is to have 1 of these client hello record caches per cluster, rather than a global state.

Sorry, my wording confused things. All I was referring to is that when you restart a strike register with a clean slate, you need to wait the window period of time before accepting any new entries. The reason is because of this race:

T1: Strike register accepts key K
T2: Strike register crashes, loses all memory of key K
T3: Strike register restarts
T4: Strike register accepts K again

To avoid that, the register needs to have a pause on start-up. Or it can record everything durably, but that's very slow. The register can still respond with microseconds during ordinary operation.
Clearly, I need better wording.

colmmacc · 2017-05-04T23:04:51Z

draft-ietf-tls-tls13.md

+weaker anti-replay defense because of the difficulty reliably
+storing and retrieving the received ClientHello messages.
+
+### Stateless Time-Based Anti-Replay {#stateless-anti-replay}


I think stateless mitigation is pointless, as it doesn't bound the number of replays, but some notes anyway ...

"Limited" should probably be in the subsection heading.

colmmacc · 2017-05-04T23:12:07Z

draft-ietf-tls-tls13.md

+handshake. Clock skew distributions are not
+symmetric, so the optimal tradeoff may involve an asymmetric range
+of permissible mismatch values.
+


Here I would suggest adding something that says:

Note that while stateless anti-replay can bound over how long in time a packet may be replayed, the total amount of replays tolerated is bounded by bandwidth and system capacity. This can be thousands to billions of replays in real-world settings.

And I'd argue for adding this too:

Stateless anti-replay SHOULD NOT be used in environments without strong assurance of application and system behavior and MUST NOT be used in environments that must interoperate with third-party systems and applications.

I added the clarification but not the normative requirement.

colmmacc · 2017-05-04T23:14:10Z

draft-ietf-tls-tls13.md

+this enables a variety of attacks via side channels such
+as cache timing or measuring the speed of cryptographic
+operations {{Mac17}}.
+


+1 to side-effect free.

colmmacc · 2017-05-04T23:22:56Z

draft-ietf-tls-tls13.md

+described in {{stateless-anti-replay}}.
+See {{replay-0rtt}} for more information on the limitations
+of these mechanisms.
+


Here I would argue for something stronger:

"0-RTT server implementations that must interoperate with third party systems and applications MUST implement a robust anti-replay mechanism".

My reasoning here is that these a CDN or TLS accelerator that enables 0-RTT without robust anti-replay, will break other downstream systems. (For example upstream 0-RTT leading to throttle exhaustion down stream). I want clear and strong language so that there can be no ambiguity when a CVE is requested against the upstream component. It's not ok imo to break a basic assumption about the internet like that.

martinthomson

I'd have preferred to see the nonce in a different PR.

martinthomson · 2017-05-05T00:25:56Z

draft-ietf-tls-tls13.md

+duplicates. However, recording all ClientHellos causes state to grow
+without bound, so in practice the server must instead record
+ClientHellos within a given time window based on the
+"obfuscated_ticket_age" value provided by the client.


I would instead say "Recording all ClientHellos causes state to grow without bound. A server can instead record ClientHellos within a given time window and use the "obfuscated_ticket_age" to ensure that tickets aren't reused outside that window."

MT's version is better, yes.

martinthomson · 2017-05-05T00:31:33Z

draft-ietf-tls-tls13.md

+client sent the ClientHello as:
+
+~~~~
+    creation time + (client's view - RTT estimate/2)


It's half an RTT for sure, but I'm not clear on why you would want to bucket based on when the client creates the ClientHello as opposed to when you receive it. For any given ticket, the RTT value is a constant, so all you are doing is adding work.

BTW, there's a simpler model for handling ticket ages in general. The server stores the value now()+RTT-ticket_age_add in the ticket (in ekr's example, this is 200-taa). Then when the server receives the ticket, it extracts that, adds the obfuscated elapsed time value (1000+taa) and compares that to the current time (1200) with whatever allowance for slop you want.

martinthomson · 2017-05-05T00:32:31Z

draft-ietf-tls-tls13.md

+
+2. If the ClientHello matches an existing ClientHello, then
+   abort the handshake using an "illegal_parameter" alert
+   (this should never happen in a functional system).


Ahh hipster crypto to the rescue.

Efficient storage isn't so much the problem as global synchronization within reasonable time frames.

martinthomson · 2017-05-05T00:35:04Z

draft-ietf-tls-tls13.md

+   (this should never happen in a functional system).
+
+3. Otherwise, store the ClientHello during the window
+   and accept 0-RTT.


If the ClientHello needs to be valid, then polluting the cache is as trivial as just creating new and different ClientHello values. In a way, the binder is just a way of having the other side calculate your hash for you.

martinthomson · 2017-05-05T00:37:26Z

draft-ietf-tls-tls13.md

+
+3. Otherwise, store the ClientHello during the window
+   and accept 0-RTT.
+


That's probably not going to fly. The window is large and waiting that long would kill all the benefits that 0-RTT provides. I would instead recognize that challenges exist in synchronizing state across participating nodes. See Erik Nygren's comments on the list that amount to basically "not gonna happen", which I agree with.

It's fine to recommend this design, but the need to have globally consistent state is a massive hurdle.

martinthomson · 2017-05-05T00:55:56Z

draft-ietf-tls-tls13.md

+this enables a variety of attacks via side channels such
+as cache timing or measuring the speed of cryptographic
+operations {{Mac17}}.
+


First of all, I would talk about "actions" rather than requests. The things that the server does in response to receiving 0-RTT are what will be exploited.

Side-effect free is useful, but forbidding that doesn't really cover it. In @enygren's example, the side effects are relevant, but the primary effect (creation/update of a resource vs. removal) is what we're really concerned with. The only way to ensure that this is perfectly safe is to use the "safe" definition in HTTP - that is the request does nothing but generate a response. And even then, it's rare that such a request is ever free from side effects or side channels.

This risks us defining something that is very HTTP-centric. I would prefer that we instead say that idempotency is desirable for the actions that the server takes, but that idempotency could be insufficient. That is more or less what the text here is getting at.

martinthomson · 2017-05-05T00:57:55Z

draft-ietf-tls-tls13.md

+fall back to 1-RTT and process the data upon application layer
+replay. The scale of this attack is limited by the client's
+willingness to replay and therefore only allows a small number of
+replays, which will also use different encryption keys.


I would remove the "therefore only allows a small number of replays". That's all up to the client. I don't consider 10 to be small, which is where we are at in Firefox.

Again I agree with MT

I changed "small" to "limited"

martinthomson · 2017-05-05T00:58:44Z

draft-ietf-tls-tls13.md

+{{stateless-anti-replay}} only prevents replay outside the
+time window.
+
+


This is pretty obvious, but worth stating, I think.

martinthomson · 2017-05-05T01:01:45Z

Hmm, it seems like some of my replies look like new comments. I clearly fail at GitHib.

ekr · 2017-05-05T01:07:49Z

@martinthomson: I guess I'm writing badly, but you're misunderstanding "store". You accept 0-RTT and then you process the 0-RTT data, but you store a copy of the CH (or the hash) during the window so you don't accept a replay. This doesn't involve delaying the processing of the CH or the EarlyData at all.

martinthomson · 2017-05-05T01:10:06Z

re: store, I was responding to @colmmacc, where he suggested that you have to wait for propagation of storage attempts from all nodes in the cluster.

kaduk · 2017-05-05T03:11:06Z

draft-ietf-tls-tls13.md

+all 0-RTT data and for PSK usage when PSK is used without DH.
+
+Because this mechanism requires sharing the session database between
+server nodes, it may be hard to achieve high rates of PSK and and


"between server nodes in environments with multiple servers acting as endpoints for the same service"

kaduk · 2017-05-05T03:12:12Z

draft-ietf-tls-tls13.md

+and these PSKs are deleted upon use, then connections established
+using one PSK enjoy forward security with respect to other PSKs
+established on the same connection. This is a security advantage for
+all 0-RTT data and for PSK usage when PSK is used without DH.


I'm not sure this part really fits in the current exposition as-is. (Also, doesn't the addition of a per-ticket nonce into the PSk ticket derivation give self-contained tickets the same forward secrecy property?)

No, because compromise of the STEK leads to compromise of all tickets.

Oh, database-key tickets certainly have better forward security properties than self-contained tickets. I'm just not sure about what the "with respect to other PSKs established on the same connection" means.

I'll see what I can do to rewrite it.

kaduk · 2017-05-05T03:14:41Z

draft-ietf-tls-tls13.md

+server nodes, it may be hard to achieve high rates of PSK and and
+0-RTT success when compared with self-encrypted tickets which do not
+require consistent server-side storage for basic functionality but
+only for 0-RTT anti-replay.


There should probably be some more clarification that 0-RTT success and PSK success are partially independent, and that tickets can still be used for PSK even if the single-use property cannot be guaranteed; that is, PSK can succeed even in cases where 0-RTT must be rejected for safety. (Unless I misunderstand?)

kaduk · 2017-05-05T03:15:10Z

draft-ietf-tls-tls13.md

+duplicates. However, recording all ClientHellos causes state to grow
+without bound, so in practice the server must instead record
+ClientHellos within a given time window based on the
+"obfuscated_ticket_age" value provided by the client.


MT's version is better, yes.

kaduk · 2017-05-05T03:20:53Z

draft-ietf-tls-tls13.md

+client sent the ClientHello as:
+
+~~~~
+    creation time + (client's view - RTT estimate/2)


I tend to agree with Nygren about not giving the attacker more information -- that is, don't hard-fail and just fall back to 1-RTT [unless you're under attack and need to shed load]. The 1-RTT will fail for the attacker's replays, of course.

kaduk · 2017-05-05T03:26:22Z

draft-ietf-tls-tls13.md

+server SHOULD reject early data and fall back to a full 1-RTT
+handshake. Clock skew distributions are not
+symmetric, so the optimal tradeoff may involve an asymmetric range
+of permissible mismatch values.


Once the discussion above about storing received ClientHello(-related stuff) settles, we should probably normalize this text with what we end up with there.

Also, a server could rate-limit how often it accepts 0-RTT, to provide some reduction in the amount of replay possible. The amount of reduction gained probably is not enough to make it worth doing, but I'll toss it out there.

kaduk · 2017-05-05T03:27:22Z

draft-ietf-tls-tls13.md

+TLS-using applications. Specifically, if applications are not
+engineered to be idempotent, then duplication of requests
+may cause side effects (e.g., purchasing an item or transferring
+money) to be duplicated, thus harming the site or the user.


I think this is some HTTPS mindset sneaking on. (Which is not necessarily wrong, just something to be aware of.)

kaduk · 2017-05-05T03:28:41Z

draft-ietf-tls-tls13.md

+fall back to 1-RTT and process the data upon application layer
+replay. The scale of this attack is limited by the client's
+willingness to replay and therefore only allows a small number of
+replays, which will also use different encryption keys.


Again I agree with MT

kaduk · 2017-05-05T03:29:17Z

draft-ietf-tls-tls13.md

+have multiple copies of the data be accepted during the replication
+window. The stateless mechanism described in
+{{stateless-anti-replay}} only prevents replay outside the
+time window.


probably should reiterate that this can be tens or hundreds of thousands of replays.

I added that separately.

In the main body text, not the security considerations, if I'm reading the line numbers correctly.
The security considerations might do well to reiterate the consequences of billions of replays (e.g., Colm's analysis).

kaduk · 2017-05-05T03:29:52Z

draft-ietf-tls-tls13.md

+{{stateless-anti-replay}} only prevents replay outside the
+time window.
+
+


Yeah, worth stating again. Maybe also that the application profile should tell the client to do so.

isonmad · 2017-05-05T19:43:29Z

draft-ietf-tls-tls13.md

@@ -3593,6 +3548,127 @@ appropriate application traffic key as described in {{updating-traffic-keys}}.
 In particular, this includes any alerts sent by the
 server in response to client Certificate and CertificateVerify messages.

+## 0-RTT and Anti-Replay {#replay-time}


Not that it matters much, but should this section be labeled {#anti-replay} or something else instead? The old {#replay-time} section was named that when it only described the stateless time-mismatch mechanism.

kaduk

In general I'm happy with the direction this is going in, but think a few more tweaks are in order.

kaduk · 2017-05-18T01:33:47Z

draft-ietf-tls-tls13.md

+of these mechanisms.
+
+Clients are unable to determine which, if any, of these mechanisms
+servers actually implement and therefore MUST only send early


This statement may be a little stronger than reality, in that a client can intentionally replay things and see whether it gets accepted right away, and after 20 seconds. The first two methods should not be distinguishable to the client, of course, though.

kaduk · 2017-05-18T01:36:17Z

draft-ietf-tls-tls13.md

+all 0-RTT data and for PSK usage when PSK is used without DH.
+
+Because this mechanism requires sharing the session database between
+server nodes, in environments with multiple distributed servers


The sharing is only necessary in such environments, so maybe
"between server nodes in environments with multiple distributed servers, in such environments it may be hard"?

kaduk · 2017-05-18T01:47:07Z

draft-ietf-tls-tls13.md

+the round trip time between client and server. I.e.,
+
+~~~~
+    adjusted_creation_time = creation time + estimated RTT


Hmm, I bet there are subtle things an attacker could do to influence the estimated RTT that do not require delayingn the actual NST and/or ClientHello messages, which could throw a wrench into this.

kaduk · 2017-05-18T02:16:59Z

draft-ietf-tls-tls13.md

+    expected_arrival_time = adjusted_creation_time + client's ticket age
+~~~~
+
+For a given storage window, the server implements anti-replay as


Do we need to introduce the phrase "storage window" somehow (or reword)?

kaduk · 2017-05-18T02:17:19Z

draft-ietf-tls-tls13.md

+For a given storage window, the server implements anti-replay as
+follows.
+
+1. Verify the PSK binder.


"What do I do if the verification fails?"

kaduk · 2017-05-18T02:27:22Z

draft-ietf-tls-tls13.md

+of permissible mismatch values.
+
+Note that while stateless anti-replay can bound over how long in time
+a packet may be replayed, the total amount of replays tolerated is


"amount" is not pluralizable; use just "amount of replay tolerated"

Actually, "amount" is pluralizable, just quirky in how it's applied.
A quick search result: https://english.stackexchange.com/a/254372

I agree that "amounts" isn't valid here, however with the potential to use "replays" to refer to each replayed message and "replay" to refer to the concept of replay, both the current text and this suggestion are valid. English can be weird. I sorta lean slightly towards kaduk's suggested wording, but whatever ekr prefers or a coin flip to chose is fine by me. ;)

kaduk · 2017-05-18T02:29:21Z

draft-ietf-tls-tls13.md

-(PSK) binding between the ticket value and the resumption master secret.
+At any time after the server has received the client Finished message,
+it MAY send a NewSessionTicket message. This message creates a
+pre-shared key (PSK) binding between the ticket value and a secret


"PSK binding" is perhaps a confusing term to use, given that we have "PSK binders" that are different.
Maybe "association" or "relationship"?

kaduk · 2017-05-18T02:32:37Z

draft-ietf-tls-tls13.md

+as cache timing or measuring the speed of cryptographic
+operations {{Mac17}}.
+
+The limited anti-replay described in {{anti-replay}} are intended to


"anti-replay" is singular and would take "is", but I think this is supposed to be "anti-replay mechanisms".

kaduk · 2017-05-18T02:34:59Z

draft-ietf-tls-tls13.md

+(which processes the data immediately) and another cluster which will
+fall back to 1-RTT and process the data upon application layer
+replay. The scale of this attack is limited by the client's
+willingness to replay and therefore only allows a limited number of


Is the different-cluster attack limited by the client's willingness to replay?
I guess it relies on the fallback to 1-RTT when the 0-RTT attempt is blackholed, so that's a "yes".

kaduk · 2017-05-18T02:36:49Z

draft-ietf-tls-tls13.md

+have multiple copies of the data be accepted during the replication
+window. The stateless mechanism described in
+{{stateless-anti-replay}} only prevents replay outside the
+time window.


In the main body text, not the security considerations, if I'm reading the line numbers correctly.
The security considerations might do well to reiterate the consequences of billions of replays (e.g., Colm's analysis).

mnot · 2017-05-18T03:06:21Z

draft-ietf-tls-tls13.md

-that an application is always aware that it is sending or receiving
-data that might be replayed.
+
+Clients MUST NOT send messages in early data which are not safe to


Is the target for this requirement really clients? How will they know? I think this is a requirement being placed upon protocols (as below) in how they specify client behaviour.

Two examples:

a client browser decides to only send 0-RTT messages for GET requests to the domain root

a client facebook mobile application decides to only send 0-RTT messages to request new timeline changes

I don't see how you could do that outside the client.

I think that this should bind both how protocols specify client behavior and actual client behavior.

ekr added 4 commits April 30, 2017 16:22

Fix argument to HKDF-Expand-Label

9ae609f

Editorial

5ecece3

vdukhovni reviewed May 4, 2017

View reviewed changes

enygren reviewed May 4, 2017

View reviewed changes

vdukhovni reviewed May 4, 2017

View reviewed changes

enygren reviewed May 4, 2017

View reviewed changes

knekritz reviewed May 4, 2017

View reviewed changes

colmmacc reviewed May 4, 2017

View reviewed changes

martinthomson reviewed May 5, 2017

View reviewed changes

kaduk reviewed May 5, 2017

View reviewed changes

isonmad reviewed May 5, 2017

View reviewed changes

ekr added 2 commits May 13, 2017 13:36

Various comments

3685f9e

Revised per review comments

771ed48

kaduk reviewed May 18, 2017

View reviewed changes

mnot reviewed May 18, 2017

View reviewed changes

ekr closed this Jul 3, 2017

		{{stateless-anti-replay}} only prevents replay outside the
		time window.


		3. Otherwise, store the ClientHello during the window
		and accept 0-RTT.

Anti replay #1005

Anti replay #1005

Conversation

ekr commented May 4, 2017

ekr commented May 4, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

enygren May 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

colmmacc left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson commented May 5, 2017

ekr commented May 5, 2017

martinthomson commented May 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

enygren May 4, 2017 •

edited

Loading