Re: [quicwg/base-drafts] Allow most frames in 0-RTT (#2355)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +## Replay Attacks with 0-RTT
+
+As described in Section 8 of {{!TLS13}}, use of TLS early data comes with an
+exposure to replay attack.  The use of 0-RTT in QUIC is similarly vulnerable to
+replay attack.
+
+Endpoints MUST implement and use the replay protections described in {{!TLS13}},
+however it is recognized that these protections are imperfect.  Therefore,
+additional consideration of the risk of replay are needed.
+
+QUIC is not inherently vulnerable to replay attack.  The management of QUIC
+protocol state based on the frame types defined in {{QUIC-TRANSPORT}} is not
+vulnerable to replay.  Processing of QUIC frames is idempotent and cannot result
+in invalid connection states if frames are reordered or lost.  QUIC connections
+do not produce effects that last beyond the lifetime of the connection, except
+for those produced by the application protocol that QUIC serves.

I realize that I had typed a response to this, but didn't post it...

This change would be a mistake.  TLS, like QUIC itself, is not the application protocol.  While it is true that the effects of tickets and address validation tokens last beyond the connection (and this might have some implications for the text), they are not effects that an application needs to worry about.

I would prefer to add "TLS session tickets and address validation tokens might be carried between connections, but these mechanisms are distinct from application state and require independent protection against reuse."  Or something to that effect.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355#discussion_r263146416