[quicwg/base-drafts] 71684b: Expand AEAD limits to consider multi-user security.

[Martin Thomson <[e-mail]>]

  Branch: refs/heads/aead-limits2
  Home:   https://github.com/quicwg/base-drafts
  Commit: 71684bc7e71580cffa434ca1c3255a6c980f3671
      https://github.com/quicwg/base-drafts/commit/71684bc7e71580cffa434ca1c3255a6c980f3671
  Author: Christopher Wood <[e-mail]>
  Date:   2020-06-24 (Wed, 24 Jun 2020)

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

  Log Message:
  -----------
  Expand AEAD limits to consider multi-user security.

In a typical multi-user setting, the adversary is assumed to perform some
(massive) amount of offline work to break the integrity of a single random
connection. Each user is represented as a unique (key, nonce) pair. In
considering the same threat model, we must treat each key resulting from
a KeyUpdate event as a unique user. As a result, roughly speaking, bounds
implied from the multi-user setting imply (minimally) for the lifetime of
a single connection.

Hoang et al. [1] present tight multi-user security bounds for randomized AES-GCM
(as is used in TLS 1.3 and QUIC), so we can take advantage of those for
per-connection integrity limits. (Confidentiality limits still apply per-key, as
the analysis considers only encrypted blocks, which would not change if an endpoint
updated its key or created a new connection.) In contrast, there are no multi-user
security bounds for AEAD_CHACHA20_POLY1305 or AEAD_AES_128_CCM, so we must use the
single-user bounds in their stead.

[1] https://dl.acm.org/doi/10.1145/3243734.3243816


  Commit: 89bbe1515f04766c0fa48dfd1b0fd4126fc3ecae
      https://github.com/quicwg/base-drafts/commit/89bbe1515f04766c0fa48dfd1b0fd4126fc3ecae
  Author: Christopher Wood <[e-mail]>
  Date:   2020-06-24 (Wed, 24 Jun 2020)

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

  Log Message:
  -----------
  Fix linter issues.


  Commit: 7d763fd6e71e4e1c38add4d78dbf3f7c28645f07
      https://github.com/quicwg/base-drafts/commit/7d763fd6e71e4e1c38add4d78dbf3f7c28645f07
  Author: Christopher Wood <[e-mail]>
  Date:   2020-06-29 (Mon, 29 Jun 2020)

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

  Log Message:
  -----------
  Update draft-ietf-quic-tls.md

Co-authored-by: Jana Iyengar <[e-mail]>


  Commit: 847f3c1666ca1ec23c92c72a9be998e74fb1ce68
      https://github.com/quicwg/base-drafts/commit/847f3c1666ca1ec23c92c72a9be998e74fb1ce68
  Author: Christopher Wood <[e-mail]>
  Date:   2020-06-29 (Mon, 29 Jun 2020)

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

  Log Message:
  -----------
  Update draft-ietf-quic-tls.md

Co-authored-by: Jana Iyengar <[e-mail]>


  Commit: e50a65d844bf4c09891bf873d64c9211b28f43f5
      https://github.com/quicwg/base-drafts/commit/e50a65d844bf4c09891bf873d64c9211b28f43f5
  Author: Christopher Wood <[e-mail]>
  Date:   2020-06-29 (Mon, 29 Jun 2020)

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

  Log Message:
  -----------
  Update draft-ietf-quic-tls.md

Co-authored-by: Jana Iyengar <[e-mail]>


  Commit: 69be76608b8f7a81d2e64e210121ddbbe1788c78
      https://github.com/quicwg/base-drafts/commit/69be76608b8f7a81d2e64e210121ddbbe1788c78
  Author: Christopher Wood <[e-mail]>
  Date:   2020-06-29 (Mon, 29 Jun 2020)

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

  Log Message:
  -----------
  Clarify connection close cases for the confidentiality limit.

Also, split out the integrity limit text again for parallel flow.


  Commit: 5e7bfa9688a218d75590134a116cedb3127443d0
      https://github.com/quicwg/base-drafts/commit/5e7bfa9688a218d75590134a116cedb3127443d0
  Author: Martin Thomson <[e-mail]>
  Date:   2020-07-06 (Mon, 06 Jul 2020)

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

  Log Message:
  -----------
  Update AEAD limits

This corrects an arithmetic error in the calculation of the
confidentiality limit for AES-GCM.

It also changes to using a fixed advantage target of 2^-57 for both
confidentiality and integrity.  The inconsistent use of different limits
was making it hard to reason about.  As the overall target is AE
security, the net effect of this is a factor of 2 improvement in
attacker advantage over what is in the TLS analysis, which was
2^-57+2^-60.  This moves to 2^-56 overall, which is cleaner.

In doing so, I discovered that the integrity limits for both AES-GCM and
AES-CCM were being set independent of the confidentiality limits, but
that the confidentiality limits assumed limits on the number of
forgeries.  As a result, the limits on forgeries had to be capped based
on those assumptions.


Compare: https://github.com/quicwg/base-drafts/compare/71684bc7e715%5E...5e7bfa9688a2