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

[MikkelFJ <[e-mail]>]

Proposed shortening of replay section

## 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.

The QUIC transport protocol is not vulnerable to replay attacks and does
tolerate replayed frames because all frames are idempotent and because
no state is carried across connections.

Applications might carry state across connections and can be confused by
STREAM frame content under 0-RTT keys and also by other content such as
flow control credits. Servers can be configured to reject old 0-RTT
packets but it is not perfect nor guaranteed. Only application protocols
can define semantics that are acceptable for 0-RTT sessions, if any.

A copied 0-RTT session is cheap to establish and can be exploited to
expend excessive server resources. Applications MUST account for this
overhead before accepting 0-RTT connections.

QUIC extensions SHOULD describe how replay attacks affect their
operation. Applications MUST prohibit extensions where efficient
replay mitigation strategies cannot be provided.

-- 
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#issuecomment-470329092