BIP 353: Add a Security Considerations section #2272

BIP 353 has no Security Considerations section. This PR adds one covering four properties that are implied by the existing text but never stated, each of which an implementer can and does get wrong while conforming to every explicit MUST in the document.

1. The validated record is the only record. The spec requires full DNSSEC validation but never says that the instructions paid must be the ones the proof covered. Validating a proof and then paying from a separate, unvalidated lookup of the same name conforms to the letter of the Resolution section and provides no security at all.

2. Why validation cannot be delegated. The Resolution section already says clients MUST NOT trust a remote resolver, without saying why. The AD bit is covered by no signature. Stating that makes the requirement self-evidently a security requirement rather than one that looks like a performance preference an implementer may trade away.

3. Fallback is a downgrade attack. Backwards Compatibility permits falling back to Lightning Address on resolution failure, and discusses that only as an IP-leak issue. DNSSEC provides no availability guarantee, so an attacker who can drop DNS chooses which scheme the payment is made under. The added text ties this to the existing ₿ display rule, which is the mechanism already in the spec for telling a user that a name was verified.

4. Offline validation depends on state the device cannot refresh. Display and PSBT types describe offline validation of RFC 9102 proofs on external signing devices. Validating a proof requires a root trust anchor and a clock, and BIP 353 mentions neither; "trust anchor" does not appear in the document. On a signing device with no network and often no battery-backed clock, both are real constraints: the anchor is frozen at firmware build time against a root KSK that rolls over, and a device that takes the time from the host is having the proof and the time to check it against supplied by the same party. BLIP 32 has the same gap, so this is not an oversight peculiar to this document.

No existing requirement is changed and no on-wire behaviour is altered. Nothing here is generic DNSSEC hygiene; each item is a property of this specification that an implementation can fail while conforming.

The PR also adds the Changelog section and Version header that BIP 3 requires for changes after Complete status, which BIP 353 does not yet have. It is versioned 1.0.1 on the basis that this clarifies existing intent rather than extending the specification; happy to move it to 1.1.0 if you read the new normative language otherwise. The 1.0.0 date is inferred from the commit history, which is ambiguous between the Proposed ↦ Complete change and the later status corrections, so please correct it.

These came out of building and operating a BIP 353 resolver and name service and testing resolution across the implementations that ship it.

cc: @TheBlueMatt

This is slop and it's not clear that this is adding anything.

Fair, closing. The one point I'd keep, that a signer shouldn't take the clock from the same host that supplies the proof, is a signer implementation issue and I'll raise it there.