[quicwg/base-drafts] 9400c2: Replay protection is the responsibility of applica...

Martin Thomson <noreply@github.com> Wed, 06 February 2019 05:32 UTC

Date: Tue, 05 Feb 2019 21:32:21 -0800
From: Martin Thomson <noreply@github.com>
To: quic-issues@ietf.org
Message-ID: <quicwg/base-drafts/push/refs/heads/0rtt-reset/fdfb19-9400c2@github.com>
Subject: [quicwg/base-drafts] 9400c2: Replay protection is the responsibility of applica...
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/O4fdC3mN12hNjxDNftwW9SGSFs4>
Precedence: list

  Branch: refs/heads/0rtt-reset
  Home:   https://github.com/quicwg/base-drafts
  Commit: 9400c2f9b2c5a235ce15377538bc8dc354467f39
      https://github.com/quicwg/base-drafts/commit/9400c2f9b2c5a235ce15377538bc8dc354467f39
  Author: Martin Thomson <mt@lowentropy.net>
  Date:   2019-02-06 (Wed, 06 Feb 2019)

  Changed paths:
    M draft-ietf-quic-tls.md

  Log Message:
  -----------
  Replay protection is the responsibility of application protocols

This is based on my recent conclusions about this subject.  It rewrites
the advice here by observing that QUIC does not inherently present a
replay risk. Instead, application protocols, in their use of QUIC, might
create an exposure to replay attack.

Rather than try to perform an analysis in the transport, based on
incomplete information, it is better to outline some risks (STREAM seems
like the only obvious one here, frankly, though I've pointed out a
couple of anti-patterns that might have accompanying replay risks) and
let the application protocol designers perform a more complete analysis.

We did that analysis for HTTP.  I believe that to be sufficient.  Though
I might include mention of the fact that stream cancellation and other
h2 mechanisms don't carry application semantics, but that is not a major
source of regret.

[quicwg/base-drafts] 9400c2: Replay protection is… Martin Thomson