Define a mechanism for looking up an offer from a user/domain pair #1136
Conversation
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's far easier to validate these on parsing than to hand-validate them elsewhere. I didn't turn `alias` or `error` into this, though they're similar (`alias` can have a nul terminator). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A BOLT11 "invoice" has proven too low-level for human use in many
scenarios. Efforts like lnurl have covered the gap, but integrating
some of such higher layers into the lightning protocol itself has many
advantages.
This draft defines three new things:
1. A new invoice format. I know, this is painful, but it maps almost
1:1 to the current format (though signatures are very different),
is easier to implement, and easier to send via the lightning
network itself.
2. Formats for an "offer", which for all intents and purposes serves
as the new, persistent invoice for users.
3. Format for an "invoice_request": this is a message sent via the
lightning network itself to receive the real invoice, or can
be used directly in a send-money scenario (e.g. ATM).
The offer (for accepting payments) or invoice_request (for sending
payments) are usually presented via a QR code or similar, the replies
are sent using onion messages. Each copies fields from the prior so
it stands alone, to allow statelessness.
Features which have been deliberately omitted for the initial version:
- Recurrence.
- Invoice replacement ("don't accept that old payment!")
- Payer proof for refunds.
I need to thank everyone who gave detailed feedback, particularly:
1. Thomas H of ACINQ (https://github.com/thomash-acinq)
2. Joost Jager (https://github.com/joostjager)
3. Aditya Sharma (https://github.com/adi2011)
4. Rene Pickhardt (https://github.com/renepickhardt)
5. Bastien Teinturier (https://github.com/t-bast)
6. Valentine Wallace of LDK (https://github.com/valentinewallace)
7. Matt Corallo of LDK (https://github.com/BlueMatt)
8. Jeffrey Czyz of Square Crypto (https://github.com/jkczyz)
Also @bjarnemagnussen, @ellemouton, @animatedbarber, @617a7a,
@instagibbs, and @eupn.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Regenerated bolt12/signature-test.json; for some reason jq reordered a few fields, but it now shows the complete signature.
bolt12/format-string-test.json is now a valid offer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Offers may contain blinded paths to allow for greater recipient privacy. However, they come at a cost of increased QR code size as each hop requires a 33-byte `point` for the `next_node_id`. Allow using `short_channel_id` instead, which only requires 8 bytes. Still allow for use of `next_node_id` for cases where the blinded path may not involve channel counterparties or for long-lived offers, which may outlive the given channels.
Offers may contain blinded paths to allow for greater recipient privacy. However, they come at a cost of increased QR code size as the introduction node requires a 33-byte `point`. Define a new `sciddir_or_pubkey` fundamental type such that either a point or a reference to one in a `channel_announcement` can be used. This is backwards compatible with `point`. Use this new type for the `blinded_path` subtype's `first_node_id`.
There was a problem hiding this comment.
I'm wondering whether a BOLT change is really needed. Can't this be fully covered by lightning/blips#32 instead?
| * [`u8`:`name_len`] | ||
| * [`name_len*byte`:`name`] | ||
| * [`u8`:`domain_len`] | ||
| * [`name_len*byte`:`domain`] |
There was a problem hiding this comment.
nit:
| * [`name_len*byte`:`domain`] | |
| * [`domain_len*byte`:`domain`] |
| @@ -824,6 +825,26 @@ sender of the invoice would have to guess how many msat that was, | |||
| and could use the `invoice_error` to indicate if the recipient disagreed | |||
| with the conversion so the sender can send a new invoice. | |||
|
|
|||
| # Offer Requests | |||
|
|
|||
| `bitcoin:` URIs with a query paraketer key (case-insensitive) of `omlookup` | |||
|
what is the denial-of-service strategy on the DNS server side. |
|
Can you clarify your concern a bit here? Who are you worried about DoSing (or DDoSing?) who? |
|
Supersceded by bLIP 32 and #1180 |
Under my understanding of BIP353, The communication channel between the client and server for the negotiation of the KEY or IPSECKEY record signing the CNAME, DNAME or TXT records. There is a maximum number of requests that can be fulfilled by the server, or a resolver in answering the requests. If you There is no asymmetry at the advantage of the defender with this scheme. |
|
Still not sure what you're talking about. There is no use of KEY or IPSECKEYs in BIP 353 or general DNSSEC-signed TXT record resolution. Are you referring to DNSKEY records? Still not clear what's relevant there? Can you describe the attack you're worried about end-to-end? |
Sure, DNSKEY record is the new name of the KEY record in newer version of DNSSEC. The end-to-end discovery of the DNSKEY record by the client, that’s the point I’m worried about with BIP353. How a client can know the human name mapping to a given public key. |
|
Okay but that didn't answer my question about your high-level concerns - can you please spell out your specific concern here? What attack, by whom, done how, etc. |
|
I'm using the BIP345 terminology here, though that the point I don’t think everything is defined. Completing with RFC 4033 and following terminology. Let's say you have a security-aware resolver Alice, a lightning user Bob, a lightning merchant Caroll and an attacker Mallory. Mallory aims to disrupt the lightning merchant Caroll to sell goods and services (e.g gift cards) to the lightning user Bob. Mallory maintains a competing merchant service and can burn satoshis-denominated funds in this attack. There is no explanation in the BIP afaict, about how Alice the resolver (or whatever the DNS root) can verify that the public key associated to Caroll is effectively owned by her. Such public key being used to DNSSEC-sign records containing the payment instruction. At time T, Mallory injects in the DNS root fake records with a DNSKEY public key and a name record associated to Caroll, or whatever other identifier generated by Caroll to communicate with her merchant user. At time T+1, Caroll try to announce her DNS records and corresponding DNSSEC public key to the hierarchy of DNS resolvers. This announcement is bounced off, as there is already an existent record. From then, Mallory can launch two types of attacks:
I think this exploitation of DNS Payment Instructions gives an advantage to the already existent lightning merchants to disrupt competitors. This is not like the Bitcoin mining competition, or a new miner should be able to join the set of current miners in a censorship-resistance fashion. I don't see how BIP345 is improving on the old HTTP-based BIP70, neither how it solves the Zooko's triangle. |
This isn't a thing? DNS is centralized and hierarchical, there's no way for anyone to "inject" records into the DNS except in their own zone(s). |
There is way for the SOA records to be tampered with, while it’s initially propagating in the DNS cache over the global Internet. Zones are signed by the DNSKEY pubkey, which must themselves be fetched by the resolvers to authenticate the zones. A fake DNSKEY pubkey for Mallory can be injected to the resolver fetching a DNSKEY for Caroll the lightning merchant. As you’re pointing to DNS is centralized and hierarchical, so it compares well to what is underscored in BIP353, on the (c) drawback about the bloated TLS Certificate Authority. So how this DNSSEC-signed payment info is comparing with the old HTTP-based BIP70 is not clear. |
|
It sounds like you think you've identified a vulnerability in DNSSEC itself. I suggest you go through the responsible disclosure process with DNS server software (bind/unbound/etc). |
I’ll check what the DNS server softwares are doing and the DNSSEC operational guidelines are saying on that in practice, if those guidelins say anything. More generally, I still think that BIP353, given if it’s for an usage in the bitcoin / lightning world where an adversary can jam or denial-of-service to gain a monetary reward, is natively suffering from massive squatting of the domain space. I don’t believe traditional internet peer-to-peer gaming servers are as exposed than let’s say LSPs which can have their whole payment protocol flows tampered by. A more robust or amended version of BIP353 could actually make the DNS records declared in cleartext or stamped in the chain itself... |
Based on #798 and working with https://github.com/TheBlueMatt/bips/blob/2024-02-dns-payment-instructions/bip-XXXX.mediawiki and lightning/blips#32 this defines a mechanism for mapping human-readable names to lightning offers. See the bLIP for a more detailed description in how the process works.