Add a PSBT per-output field for BIP 353 DNSSEC Proofs

TheBlueMatt commented at 6:35 pm on July 28, 2024: contributor

When using BIP 353 for on-chain addresses (incl silent payments),
it is useful to be able to include DNSSEC proof information in
outputs of a PSBT, which we enable here by defining a standard
field for it.

jonatack added the label Proposed BIP modification on Jul 28, 2024

jonatack requested review from achow101 on Jul 28, 2024

in bip-0174.mediawiki:667 in 64185ba458 outdated

658@@ -659,6 +659,17 @@ required for aggregation. If sorting was done, then the keys must be in the sort
659 | 0, 2
660 | [[bip-0373.mediawiki|373]]
661 |-
662+| BIP 353 DNSSEC proof
663+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
664+| None
665+| No key data
666+| <tt><RFC 9102-formatted DNSSEC Proof></tt>
667+| An RFC 9102 DNSSEC `Authentication Chain Data` without the `ExtSupportLifetime` field (i.e. a series of RFC 9102 `AuthenticationChain`s) providing a DNSSEC proof to a BIP 353 DNS TXT record.

jonatack commented at 6:59 pm on July 28, 2024:

0| An RFC 9102 DNSSEC <tt>Authentication Chain Data</tt> without the <tt>ExtSupportLifetime</tt> field (i.e. a series of RFC 9102 <tt>AuthenticationChain</tt>s) providing a DNSSEC proof to a BIP 353 DNS TXT record.

TheBlueMatt commented at 1:44 pm on July 29, 2024:

It seems to render fine either way, no? The <> version makes reading the plaintext much more difficult.

achow101 commented at 8:21 pm on August 19, 2024:

backticks don’t render as code formatting, if that was what you were trying to do. Otherwise, I’d suggest using single quotes here instead of backticks.

jonatack added the label Pending acceptance on Jul 28, 2024

TheBlueMatt force-pushed on Jul 30, 2024

TheBlueMatt commented at 4:53 pm on July 30, 2024: contributor

Realized this doesn’t actually work without the name itself, so force-pushed that in.

in bip-0353.mediawiki:73 in 15656d5819 outdated

69@@ -70,12 +70,37 @@ Payment instructions which do contain on-chain addresses which will be re-used S
70 
71 === Display ===
72 
73-When displaying a verified human-readable address, wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.
74+When displaying a verified human-readable name, wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.

murchandamus commented at 5:46 pm on July 30, 2024:

0When displaying a verified human-readable name, wallets SHOULD prefix it with ₿, i.e. ₿`user`@`domain`. They SHOULD parse recipient information in both `user`@`domain` and ₿`user`@`domain` forms and resolve such an entry into recipient information using the above record. For the avoidance of doubt, the ₿ is *not* included in the DNS label which is resolved.

murchandamus commented at 5:48 pm on July 30, 2024: contributor

Seems reasonable. @achow101, could you take a look please?

Consistently refer to them as "human-readable names", not addresses

It seems confusing to call BIP 353 names "addresses", and most of
the BIP refers to them as "names", but a few "human-readable
addresses" snuck in in a recent change, which are fixed here.

eeaf21d882

TheBlueMatt force-pushed on Jul 31, 2024

murchandamus assigned murchandamus on Aug 6, 2024

murchandamus unassigned murchandamus on Aug 6, 2024

murchandamus assigned achow101 on Aug 6, 2024

Freeanjel approved

in bip-0353.mediawiki:98 in 42a0e9a195 outdated

93+| BIP 353 DNSSEC proof
94+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>
95+| None
96+| <tt><1-byte-length-prefixed BIP 353 human-readable name without the ₿ prefix><RFC 9102-formatted DNSSEC Proof></tt>
97+| A BIP 353 human-readable name (without the ₿ prefix), prefixed by a 1-byte length.
98+Followed by an RFC 9102 DNSSEC `Authentication Chain Data` without the `ExtSupportLifetime` field (i.e. a series of RFC 9102 `AuthenticationChain`s) providing a DNSSEC proof to a BIP 353 DNS TXT record.

achow101 commented at 8:24 pm on August 19, 2024:

A link to the relevant RFC and section would be nice. But I find the RFC to be a bit vague here, so it might be easier to just write out what the serialization is supposed to be?

achow101 commented at 8:48 pm on August 19, 2024:

Since a single RRSIG can cover multiple RRs in the response, those RRs would need to be included in order to verify the signature. Does there need to be any specific handling and/or disallowing of such RRSets?

RRSIG also specifies a validity period for the signature. How should validators deal with those, especially since a PSBT can take a lot of time between updating and signing.

TheBlueMatt commented at 1:57 am on August 25, 2024:

A link to the relevant RFC and section would be nice.

You mean like an HTTP link?

But I find the RFC to be a bit vague here, so it might be easier to just write out what the serialization is supposed to be?

Not sure I can be much more accurate. Its basically just “a series of DNS records written out in DNS record format”, but that’s not exactly clear either…

Since a single RRSIG can cover multiple RRs in the response, those RRs would need to be included in order to verify the signature. Does there need to be any specific handling and/or disallowing of such RRSets?

Those would need to be included. I believe RFC 9102 is clear here - “In either case, the chain of RRsets MUST be accompanied by the full set of DNS records needed to authenticate the TLSA record set or its denial of existence up the DNS hierarchy to either the root zone or another trust anchor mutually configured by the TLS server and client.”

RRSIG also specifies a validity period for the signature. How should validators deal with those, especially since a PSBT can take a lot of time between updating and signing.

That’s deliberately left undefined here. The library I wrote exposes the proof validity start and end time as well as the TTL, but I imagine most users will ignore the TTL, and probably should, only paying attention to the proof validity start and end times.

achow101 commented at 8:34 pm on August 19, 2024: member

Realized this doesn’t actually work without the name itself, so force-pushed that in.

Wouldn’t the Authentication Chain already contain the name since it has the record itself?

in bip-0353.mediawiki:96 in 42a0e9a195 outdated

89+! Versions Requiring Inclusion
90+! Versions Requiring Exclusion
91+! Versions Allowing Inclusion
92+|-
93+| BIP 353 DNSSEC proof
94+| <tt>PSBT_OUT_DNSSEC_PROOF = 0x35</tt>

achow101 commented at 8:49 pm on August 19, 2024:

It’d be nice to just go in order… the next field available is 0x09.

TheBlueMatt commented at 1:59 am on August 25, 2024:

I liked the DNS port (53) :) But I can do whatever, it doesn’t matter…

bitcoin deleted a comment on Aug 19, 2024

bigspider commented at 12:36 pm on August 22, 2024: contributor

As I understand it, the semantic meaning is to provide a form of authentication of the output, in order to establish “this output belongs to a certain identity”.

Perhaps it would be worth having a generic keytype called maybe PSBT_OUT_AUTHENTICATION_PROOF, and use the keydata to label the type of authentication, for example reserving keydata = 0x00 for the DNSSEC_PROOF as per the rest of the specs, and leaving the meaning undefined for any other keydata. It costs a single additional byte per output, but avoids having to define a new keytype if/when other approaches to the authentication of outputs are proposed.

TheBlueMatt commented at 1:58 am on August 25, 2024: contributor

Wouldn’t the Authentication Chain already contain the name since it has the record itself?

Technically yes, but the Authentication Chain is just a list of records “in no particular order”, which makes it somewhat annoying to figure out the name. If you have a wildcard it could even be impossible.

Add a PSBT per-output field for BIP 353 DNSSEC Proofs

When using BIP 353 for on-chain addresses (incl silent payments),
it is useful to be able to include DNSSEC proof information in
outputs of a PSBT, which we enable here by defining a standard
field for it.

b0d5a07943

TheBlueMatt force-pushed on Aug 29, 2024

achow101 commented at 7:34 pm on August 29, 2024: member

ACK b0d5a0794333bfcf103c3642b168c4338320c48e

murchandamus approved

murchandamus commented at 8:15 pm on August 29, 2024: contributor

Looks good to me, merging this as it only adds specification for how to handle PSBTs and adjusts “human-readable address” to “human-readable name in the BIP text. Also has sign-off from BIP 174 author.

murchandamus merged this on Aug 29, 2024

murchandamus closed this on Aug 29, 2024

jonatack commented at 8:25 pm on August 29, 2024: member

Post-merge lgtm

jonatack removed the label Pending acceptance on Aug 29, 2024

Add a PSBT per-output field for BIP 353 DNSSEC Proofs #1657