Add a draft threat model and wire it for discoverability

[potiuk]

Motivation

The Pekko PMC asked the ASF Security team for a draft threat model to refine, as
preparation for a Claude security scan. This is the companion to
the same change in apache/pekko — that model
covers the actor, stream, remoting and cluster layers, and this one does not restate them.

docs/src/main/paradox/security.md already carries a "Security model" section, and it
makes the most consequential statement in this document: applications "should not be
exposed to the public internet directly", and DoS resistance is claimed only as
"pretty well under most known Denial of Service attacks". But that is three sentences,
and the quantitative envelope that actually bounds untrusted input — the parsing limits in
http-core's reference.conf — is not connected to it anywhere.

Separately, the AGENTS.md → SECURITY.md chain that a scanning agent follows to locate
a project's model does not resolve today: there is no SECURITY.md in the repo.

Modification

• THREAT_MODEL.md — a v0 draft. §5a collects the shipped parsing limits,
  timeouts and CORS defaults as the model's quantitative spine; §8 states the six
  default-on properties they underwrite. Every claim is tagged (documented) with a
  citation or (inferred) with a matching question in §14.
• SECURITY.md — reporting policy (security@apache.org; Pekko does not operate a
  separate project security list), plus the three points that catch most reporters.
• AGENTS.md — a two-line ## Security section pointing at both.

Nothing security.md asserts has been dropped or weakened — §15 back-maps each
existing statement to the section that now carries it.

Result

The chain AGENTS.md → SECURITY.md → THREAT_MODEL.md resolves on main, and triagers
get a citable document with a closed set of dispositions (§13).

Worth noting in contrast to the apache/pekko model: every §8 property here is
default-on. Pekko HTTP's parsing limits, timeouts, strict URI/cookie parsing and
response-splitting protection all ship enabled. The soft spot is not the defaults, it is
the boundary of the DoS claim.

§14 holds 10 questions, each stated as a proposed answer — confirming or correcting is
enough. The two worth reading first:

• Q1 — where exactly is the DoS line? security.md's claim is deliberately graded, and
  triage needs a split. Proposed: a request within all §5a limits that causes
  super-linear CPU or memory is VALID; anything requiring limits to be raised, or
  requiring request volume rather than request content, is out of model because volume
  defence is the fronting proxy's job. Is that the intended reading?
• Q2 — the http-cors defaults. The module ships allowed-origins = "*" together with
  allow-credentials = yes. Per its own reference.conf, that combination does not
  send a literal * — it echoes the request's Origin and allows credentials. Two things
  bound how alarming that is: cors() is opt-in, and the interaction is documented. Is the
  default deliberate, or should it change?

This is a draft and should not be treated as canonical until at least Q1 and Q2 are
answered. Happy to fold answers in, or hand it over entirely — the PMC owns the document.

Tests

Not run - docs only

References

None - requested by the Pekko PMC chair on the ASF security scan thread

[pjfanning]

Thanks Jarek. My plan is to concentrate on apache/pekko#3478 and to return to this when we make progress on that. If you prefer, we can merge this and discuss with the Pekko PMC how to complete it.

[potiuk]

Sure. Tak your time - and indeed pekko one is more important .