Permit 0-RTT after Retry and VN #1514

martinthomson · 2018-07-03T05:58:23Z

After the discussion on #1507, I've been convinced that there is no real
value in preventing a client from attempting 0-RTT after a Retry. And,
it would seem like Version Negotiation has essentially the same
properties, so excluding it would be inconsistent.

This allows this, explores the consequences for packet numbers (don't
reset them!), and updates the recovery text to include Version
Negotiation.

Closes #1507.

(Note the target of this PR. Two pieces of work are in flight here. Don't just merge and walk away or something could get lost.)

kazuho · 2018-07-03T06:11:04Z

draft-ietf-quic-transport.md

@@ -770,6 +776,28 @@ are in a different packet number space to other packets (see
 {{packet-numbers}}).


+### 0-RTT Packet Numbers {#retry-0rtt-pn}
+
+Packet numbers for 0-RTT protected packets use the same space as 0-RTT protected


"as 0-RTT protected" -> "as 1-RTT protected"?

mikkelfj · 2018-07-03T13:42:46Z

draft-ietf-quic-transport.md

-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it can include that value in the
-Token field of its Initial packet.
+If the client has an token received in a NEW_TOKEN frame on a previous


mikkelfj · 2018-07-03T13:45:34Z

draft-ietf-quic-transport.md

+packets to the connection ID provided by the server.  A client that sends
+additional 0-RTT packets MUST NOT reset the packet number to 0 after a Retry
+packet, see {{retry-0rtt-pn}}.
+


sugg: A server MAY reject a redirected 0-RTT attempt because the DCID does not match the 0-RTT token.

Not sure that I understand the suggestion.

Me neither - the thought was to use the dcid given in the retry - which could lead to a target that does not accept the tokens. But dcid cannot change from when tokens were forged.

mikkelfj · 2018-07-03T13:48:16Z

draft-ietf-quic-transport.md

+address or network interface.  Reusing a token on different network paths would
+allow activity to be linked between paths (see {{migration-linkability}}).  A
+client needs to start the connection process over if it migrates prior to
+completing the handshake.



Redundant explanation using both "correlate" and "linked" in separate sentences.

ianswett · 2018-07-03T13:30:43Z

draft-ietf-quic-transport.md

-If the client has a token received in a NEW_TOKEN frame on a previous connection
-to what it believes to be the same server, it can include that value in the
-Token field of its Initial packet.
+If the client has an token received in a NEW_TOKEN frame on a previous


ianswett · 2018-07-03T13:52:49Z

draft-ietf-quic-transport.md

+After a client receives a Retry or Version Negotiation packet, it MAY attempt to
+send data in 0-RTT packets after it sends a new Initial packet.  However, a
+client MUST NOT reset the packet number it uses for 0-RTT packets.  The keys
+used to protect 0-RTT keys are not guaranteed to change as a result of


Technically, I don't think there's even a mechanism the 0-RTT keys could be changed via Retry, so I'd say "not likely to change"?

I struggled with finding the right words, but I have a plan now. They won't change unless the cryptographic handshake does. (And I will leave unsaid the reasons why it might not - we have reason to believe that Retry will never cause a change and VN might, but that detail is elsewhere and if we follow the justification rabbit-hole to the end we'll be singing about oysters in no time.)

MikeBishop

I eventually figured out what you actually meant, but it didn't click for me reading the text the first time. If it's not just me, perhaps more/different explanation is in order.

The key point is that if the CID doesn't change, the 0-RTT packets from before and after the Retry can both be accepted and processed as part of the connection, either via buffering or reordering. So you have to resend all that data, but can't reuse those packet numbers.

MikeBishop · 2018-07-05T16:02:18Z

draft-ietf-quic-recovery.md

-NOT be treated as an acknowledgment for the Initial, but it MAY be used for an
-RTT measurement.
+Either packet indicates that the Initial was received but not processed.  Either
+packet cannot be treated as an acknowledgment for the Initial, but they MAY be


"Either ... cannot" feels awkward. Maybe "Neither packet can be...."?

MikeBishop · 2018-07-05T16:05:52Z

draft-ietf-quic-transport.md

-Token field of its Initial packet.
+If the client has a token received in a NEW_TOKEN frame on a previous
+connection to what it believes to be the same server, it can include that value
+in the Token field of its Initial packet.


This paragraph looks like a rewrap to a shorter line length than the rest of the document. The original layout appears to be fine.

MikeBishop · 2018-07-05T16:07:29Z

draft-ietf-quic-transport.md

+connections to be identified as coming from the same endpoint (see also
+{{migration-linkability}}).  A client MUST NOT reuse a token if it believes that
+its point of network attachment has changed; that is, if there is a change in
+its local IP address or network interface.  A client MUST start the connection


I know you didn't change this text, but this seems to preclude clients keeping a cache of tokens and the associated network connections. For example, a mobile device that went to Wi-Fi could keep the cellular token in expectation that it will be on cellular again. Perhaps the better prohibition is that you MUST NOT use the token on a different network than where you received it?

MikeBishop · 2018-07-05T16:10:17Z

draft-ietf-quic-transport.md

+
+After a client receives a Retry or Version Negotiation packet, it MAY attempt to
+send data in 0-RTT packets after it sends a new Initial packet.  However, a
+client MUST NOT reset the packet number it uses for 0-RTT packets.  The keys


If the CID doesn't change, reordering or caching could cause the first flight of 0-RTT packets to remain valid after the new Initial lands. So unless the CID changes (and maybe even if it does, if the server is trying too hard), you have to assume those packets are still outstanding but potentially lost. Maybe we should frame this in terms of fast retransmit?

I realize now the source of the confusion. You are concerned about the case where maybe all this 0-RTT is received (and can be processed). I'm more concerned about catastrophic compromise of packet protection. I think that the nonce reuse thing is more urgent.

MikeBishop · 2018-07-05T16:12:03Z

draft-ietf-quic-transport.md

@@ -1311,6 +1339,10 @@ Version Negotiation packet.
 A client MUST ignore a Version Negotiation packet that lists the client's chosen
 version.

+A client MAY attempt 0-RTT after receiving a Version Negotiation packet.  A
+client that sends additional 0-RTT packets MUST NOT reset the packet number to 0
+after a Retry packet, see {{retry-0rtt-pn}}.


Since this section is about Version Negotiation packets, the mention of Retry packets seems a non sequitur. It's fine to reset the 0-RTT packet number space after a VN packet, because the previous 0-RTT packets will be of a version unknown to the server and therefore will just be discarded (or rather, will trigger more VN packets).

It's not OK to reset the packet numbers, because you just created a two-time pad. The same key and nonce, with different inputs (the version number). That's disastrous.

The mention of Retry is a mistake though.

MikeBishop

Regardless of urgency, I think this covers both cases a little better. It might still be worth mentioning that the previous flight of 0-RTT packets could still be consumed by the server, so the client needs to consider that data as having been sent (and therefore can't change it).

mikkelfj · 2018-07-06T04:50:51Z

I think it does not matter if the packet got to a server - but it might have gotten to an attacker.

janaiyengar · 2018-07-06T23:11:12Z

draft-ietf-quic-transport.md

+packets.
+
+After a client receives a Retry or Version Negotiation packet, 0-RTT packets are
+likely to be lost or discarded by the server, especially if the server changes


s/likely to be/likely to have been/

janaiyengar · 2018-07-06T23:11:33Z

draft-ietf-quic-transport.md

+
+After a client receives a Retry or Version Negotiation packet, 0-RTT packets are
+likely to be lost or discarded by the server, especially if the server changes
+its connection ID with a Retry packet.  A client MAY attempt to send data in


s/send data/resend data/

janaiyengar · 2018-07-06T23:13:18Z

draft-ietf-quic-transport.md

+A client SHOULD NOT reuse a token.  Reusing a token could allow different
+connections to be identified as coming from the same endpoint (see also
+{{migration-linkability}}).  A client MUST NOT reuse a token if it believes that
+its point of network attachment has changed since it was last used; that is, if


This seems too strong -- see my comment on the other PR.

After the discussion on #1507, I've been convinced that there is no real value in preventing a client from attempting 0-RTT after a Retry. And, it would seem like Version Negotiation has essentially the same properties, so excluding it would be inconsistent. This allows this, explores the consequences for packet numbers (don't reset them!), and updates the recovery text to include Version Negotiation. Closes #1507.

Closes #1168.

kazuho · 2018-07-09T07:06:22Z

draft-ietf-quic-transport.md

+
+After a client receives a Retry or Version Negotiation packet, 0-RTT packets are
+likely to have been lost or discarded by the server, especially if the server
+changes its connection ID with a Retry packet.  A client MAY attempt to resend


The text after "especially if ..." seems to imply that 0-RTT packets might not have been lost in case the client receives a Version Negotiation packet.

I am not sure if that is true.

My understanding is that a Version Negotiation packet is sent by a server only if the client offers a version unknown to the server. In such case, all the 0-RTT packets would have been lost, because the format of the 0-RTT packets are version specific, and those would have been unprocessible by the server.

Yeah, this is right. In order of likelihood that packets are unusable:

VN with unsupported version

Retry w/ connection ID change

Retry w/o connection ID change or VN with preferred alternative version

I don't know why I missed that. Reworded.

ianswett

LGTM

martinthomson requested review from ekr and ianswett July 3, 2018 05:58

martinthomson added the -transport label Jul 3, 2018

kazuho reviewed Jul 3, 2018

View reviewed changes

nibanks approved these changes Jul 3, 2018

View reviewed changes

mikkelfj reviewed Jul 3, 2018

View reviewed changes

ianswett approved these changes Jul 3, 2018

View reviewed changes

MikeBishop requested changes Jul 5, 2018

View reviewed changes

MikeBishop approved these changes Jul 6, 2018

View reviewed changes

quicwg deleted a comment from mikkelfj Jul 6, 2018

janaiyengar reviewed Jul 6, 2018

View reviewed changes

martinthomson added 6 commits July 9, 2018 10:09

0-RTT, 1-RTT, same thing

88fc560

Clarify key changes

620c583

Redo fixes I already committed somewhere else, I swear

b6c48be

Refinements

e2b9137

Have been

1011f5e

martinthomson force-pushed the allow-retry-0rtt branch from 1ae029a to 1011f5e Compare July 9, 2018 00:16

Add text to the TLS spec too

2e13f0d

Closes #1168.

martinthomson force-pushed the allow-retry-0rtt branch from 80779d8 to 2e13f0d Compare July 9, 2018 04:39

Extra 'on'

25598fd

kazuho reviewed Jul 9, 2018

View reviewed changes

Remove especially if text

22deb75

ianswett approved these changes Jul 9, 2018

View reviewed changes

martinthomson changed the base branch from move-retry to master July 31, 2018 05:13

martinthomson merged commit cd6b76e into master Jul 31, 2018

martinthomson deleted the allow-retry-0rtt branch July 31, 2018 05:14

kazuho mentioned this pull request Jan 7, 2019

amplification attack using Retry and VN triggered by coalesced Initial packets #2259

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Permit 0-RTT after Retry and VN #1514

Permit 0-RTT after Retry and VN #1514

martinthomson commented Jul 3, 2018

kazuho Jul 3, 2018

mikkelfj Jul 3, 2018

mikkelfj Jul 3, 2018

martinthomson Jul 3, 2018

mikkelfj Jul 6, 2018 •

edited

Loading

mikkelfj Jul 3, 2018

ianswett Jul 3, 2018

ianswett Jul 3, 2018

martinthomson Jul 3, 2018

MikeBishop left a comment

MikeBishop Jul 5, 2018

MikeBishop Jul 5, 2018

MikeBishop Jul 5, 2018

MikeBishop Jul 5, 2018

martinthomson Jul 6, 2018

MikeBishop Jul 5, 2018

martinthomson Jul 6, 2018

MikeBishop left a comment •

edited

Loading

mikkelfj commented Jul 6, 2018

janaiyengar Jul 6, 2018

janaiyengar Jul 6, 2018

janaiyengar Jul 6, 2018

kazuho Jul 9, 2018

martinthomson Jul 9, 2018

ianswett left a comment

Permit 0-RTT after Retry and VN #1514

Permit 0-RTT after Retry and VN #1514

Conversation

martinthomson commented Jul 3, 2018

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

mikkelfj Jul 6, 2018 • 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

MikeBishop 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

MikeBishop left a comment • edited Loading

Choose a reason for hiding this comment

mikkelfj commented Jul 6, 2018

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

ianswett left a comment

Choose a reason for hiding this comment

mikkelfj Jul 6, 2018 •

edited

Loading

MikeBishop left a comment •

edited

Loading