fix(pcapng): repoint TLSKeyLabel at RFC 9850, add ECH_SECRET/ECH_CONFIG

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible -- N/A -- changelog centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• chore — anything else

---

Description of your pull request and other information

TLSKeyLabel tracked the Mozilla NSS key-log wiki, but draft-ietf-opsawg-pcapng-06 S4.7 now
points at [I-D.ietf-tls-keylogfile] (draft-05), published as RFC 9850, "The SSLKEYLOGFILE Format for TLS", whose S4.2 creates the IANA "TLS
SSLKEYLOGFILE Labels" registry.

Against that registry we were missing ECH_SECRET and ECH_CONFIG (RFC 9850 SS2.3/4.2), so
TLSKeyLabel('ECH_SECRET') raised ValueError on an otherwise-legitimate Decryption Secrets
Block. Both are added with a #: comment transcribed from the registry table; ECH_SECRET keeps
the file's # nosec B105 bandit convention for *_SECRET members, ECH_CONFIG doesn't need it.

RSA has no row in RFC 9850's registry -- it's an NSS-only label the NSS wiki records as removed
in NSS 3.34. Kept rather than deleted (removing a public member is a breaking change) and
documented as the historical exception.

Also repoints secrets_type.py's stale # NSS Key Log Format comment at RFC 9850, and cites RFC
9850 in TLSKeyLabel's docstring. Added a test pinning the member set against RFC 9850 plus the
documented RSA exception, and asserting ECH_SECRET/ECH_CONFIG/RSA all resolve.

Fixes #882

[JarryShaw]

GOOD TO GO on 3b024c00c — cross-review (opus; author sonnet). No changes required.

It went past the RFC and checked the live registry, which is the right instinct given RFC 9850's registry is Specification Required and could have moved since July 2026. Fetched https://www.iana.org/assignments/tls-parameters/tls-sslkeylogfile-labels.csv today and diffed it against the enum imported from the PR tree:

IANA registry size: 10          enum size: 11
registry - enum (MISSING from pcapkit): []
enum - registry (EXTRA in pcapkit): ['RSA']

I re-ran that fetch myself: 10 rows, the same 10 labels, and grep -c RSA over RFC 9850 returns 0 — RSA appears nowhere in the document, so the spurious-member framing holds and no registered label is missed.

Other findings, each with its own evidence:

• Fails without the fix. Replaced only pcapng.py with git show origin/main: — AssertionError: Items in the second set but not the first: 'ECH_SECRET' 'ECH_CONFIG', run=1 failures=1. A real failure on the defect, not on an import.
• # nosec B105 is right in both directions, measured with bandit 1.9.4 rather than reasoned from the substring: the PR file is clean with 8 skipped (7 pre-existing + ECH_SECRET), and stripping the marker from ECH_SECRET alone produces B105 hardcoded_password_string … pcapng.py:290. So it is load-bearing there and genuinely unnecessary on ECH_CONFIG.
• Descriptions byte-exact against the IANA CSV's unwrapped Description column, including the ECHConfig casing.
• No consumer can break. 22 TLSKeyLabel hits, all annotations, fixtures or prose; no len(), no exhaustive dispatch. The docs directive is autoclass with :undoc-members:, so the .rst needs no edit.
• 94 tests OK (skipped=1) against the PR tree, with pcapkit.__file__ printed.

And it caught an imprecision in my own issue text, which I have verified and fixed in the PR description. Draft-06 §4.7 does not literally name RFC 9850 — line 2380 reads "This format is described in [I-D.ietf-tls-keylogfile]", resolved at line 3206 as draft-ietf-tls-keylogfile-05, which was then published as RFC 9850. The substance is unaffected (that draft already registers both labels, and the draft contains zero NSS or Mozilla references, so the old pointer really is gone), but the citation chain is transitive and the description now says so.

Not verified, stated rather than glossed: make pylint / make mypy / make isort were not run, and no lint leg exists in this PR's checks — CI's "Analyze" is CodeQL. The diff is four comment lines, two enum members whose values equal their names, and one test method; the one linter with anything to say here was bandit, which was run.

CI: 55 green, 0 failed, 3 still in flight. Unpublished and unmerged, yours to merge.