From info at AndySchroder.com Mon Nov 20 14:53:54 2023 From: info at AndySchroder.com (Andy Schroder) Date: Mon, 20 Nov 2023 09:53:54 -0500 Subject: [Lightning-dev] Lightning Address in a Bolt 12 world In-Reply-To: References: <409d3008-8d26-3cab-55b0-a8bfb42b6c63@AndySchroder.com> Message-ID: <5e1ebeb9-94ce-8758-edde-3d951f52c3be@AndySchroder.com> > >> - I would omit suggesting to use DoH from the spec. DoH seems a bit >> centralized to me and that's up to the client to decide what to do. >> DNS itself is a hierarchically distributed system, so there is >> redundancy built into it (which has its flaw at the root nameserver / >> ICANN level) and it seems to me like DoH is taking much of that >> distributed design away. It seems like if you are concerned about >> your ISP snooping your traffic, you should use a tunnel so that your >> traffic is obfuscated that way, that way things are done at the IP >> level and not way up at the HTTPS level. Are you resorting to DoH >> because many ISP block traffic for DNSSEC records traffic through >> their networks? Either way, how you query DNS seems like that should >> be left up to the client and not really part of the spec. > > It is, but its worth mentioning in large part because almost certainly > ~all implementations will use it. While I agree that it'd be very nice > to not use it, in order to do so clients would need to (a) actually be > able to query TXT records, which isn't in standard operating system > libraries, so would probably mean DoH to 127.0.0.53 or so, (b) trust > the resolver's DNSSEC validation, which means having some confidence > its local, and not a coffee shop/etc. > > Given the level of trust you have to have here in the DNS resolution, > its almost certainly best to cross-validate with at least multiple DoH > services, unless you are validating the DNSSEC chain yourself (which > I'd really strongly prefer as the best solution here, but I'm unaware > of any open source code to do so). delv, part of bind9, does recursive DNSSEC validation locally: https://manpages.ubuntu.com/manpages/jammy/en/man1/delv.1.html Andy Schroder On 11/18/23 16:27, Matt Corallo wrote: > > > On 11/17/23 8:28 AM, Andy Schroder wrote: >> #Comments >> >> >> ## General >> >> - I agree that option 3 and 1 should be used. However, you say >> "clients (mobile wallets) would first make a DNS request >> corresponding to option 3, and if that fails, they would fallback to >> option 1. Domain owners would implement only one of those two >> options, depending on their DNS capabilities." . However, it seems to >> me like if we query for a specific user at the domain and it exists, >> use Option 3, but if it doesn't, then fall back to Option 1. So, they >> can actually implement both, depending on the user. > > Yea, option 1 could reasonably take precedence, however the tradeoff > in that case would be revealing *who* you're paying, not just which > service you're paying through, to any (honest but curious) DoH resolver. > >> - I would omit suggesting to use DoH from the spec. DoH seems a bit >> centralized to me and that's up to the client to decide what to do. >> DNS itself is a hierarchically distributed system, so there is >> redundancy built into it (which has its flaw at the root nameserver / >> ICANN level) and it seems to me like DoH is taking much of that >> distributed design away. It seems like if you are concerned about >> your ISP snooping your traffic, you should use a tunnel so that your >> traffic is obfuscated that way, that way things are done at the IP >> level and not way up at the HTTPS level. Are you resorting to DoH >> because many ISP block traffic for DNSSEC records traffic through >> their networks? Either way, how you query DNS seems like that should >> be left up to the client and not really part of the spec. > > It is, but its worth mentioning in large part because almost certainly > ~all implementations will use it. While I agree that it'd be very nice > to not use it, in order to do so clients would need to (a) actually be > able to query TXT records, which isn't in standard operating system > libraries, so would probably mean DoH to 127.0.0.53 or so, (b) trust > the resolver's DNSSEC validation, which means having some confidence > its local, and not a coffee shop/etc. > > Given the level of trust you have to have here in the DNS resolution, > its almost certainly best to cross-validate with at least multiple DoH > services, unless you are validating the DNSSEC chain yourself (which > I'd really strongly prefer as the best solution here, but I'm unaware > of any open source code to do so). > >> - Is there a minimum path/offer expiry? Wondering if those might be >> way lower than the DNS record expiry? Seems like we want the expiry >> of the DNS record to be less than the path expiry because there will >> be some latency in propagating a record with a new blinded path or >> offer through an organization's redundant nameservers. Also, when you >> create the offer with an expiry and add it to the DNS record, that >> expiry is part of the offer data itself and relative to when it was >> *created*, but your local computer will have an expiry that starts at >> the time you *fetched* that DNS record. > > While offers can expire arbitrarily, I anticipate users of this system > will fetch long-lived offers, eg ones that expire in a year or two. > >> - Will we hit any DNS record length limits with the blinded path or >> offer that need to be considered? > > We certainly shouldn't. You can put a full PGP key in the DNS: > > $ dig > 4f31fa50e5bd5ff45684e560fc24aeee527a43739ab611c49c51098a._openpgpkey.mattcorallo.com > type61 > >> >> ## Option 1 >> >> I think you should also add an option for a type that allows >> different users to have different blinded paths. From a scalability >> perspective, one may not want to serve all users on the same node. >> Also, the user may use their own lightning node instead of the domain >> operators. >> >> | hostname?????????????? | record type | value?????????????? | >> TTL???????? | >> |------------------------|-------------|---------------------|-------------| >> >> | bob._lnaddress.domain.com. | TXT???????? | path: | >> path expiry | >> >> >> The statement >> >> "Note that Alice cannot verify that the offer she receives is really >> from Bob: she has to TOFU (trust on first use). But that's something >> we fundamentally cannot fix if the only information Alice has is >> `bob at domain.com`. However, Alice obtains a signed statement from >> Bob's LSP that attests that `bob at domain.com` is associated with the >> Bolt12 offer she receives. If she later discovers that this was >> invalid, she can publish that proof to show the world that Bob's LSP >> is malicious" >> >> - I think should be revised to not use "LSP". We don't necessarily >> know if it is an LSP or a self hosted domain and node. It could be an >> LSP, but maybe not. >> >> - I think we should say that we cannot verify the offer *if* Bob does >> not self host and uses an LSP. If Bob self hosts, we know it's from >> Bob if DNSSEC validates and the root nameservers and the tld >> nameservers are honest. >> >> - I think there should be a QR code format that accompanies this so >> that phone apps can easily validate the path (or for option 3 below >> the offer). >> >> >> ## Option 2 >> >> >> - Seems to be a bad idea to me. You are relying on certificate >> authorities to prove the ownership of a domain? The certificate >> authorities are not an authority on domain ownership. Also, it seems >> to me like certificate authorities are a major weak link because if >> *any* certificate authority in your local trust database becomes >> faulty, *all* certificates can no longer be trusted. >> >> - This approach seems *very* unscalable because it requires the >> announcements for all domains to be gossiped to everyone? I think >> that there needs to be a decentralized DNS that is created, but this >> seems to be headed in the wrong direction. We should be able to learn >> from some of the hierarchical features of legacy DNS and build a >> truly decentralized "root", which will be more efficient. >> >> >> >> >> ## Option 3 >> >> - "The statement "Note that Alice cannot verify that the offer she >> receives is really from Bob" can apply to this option too, right? >> >> >> Andy Schroder >> >> On 11/16/23 08:51, Bastien TEINTURIER wrote: >>> Good morning list, >>> >>> Most of you already know and love lightning addresses [1]. >>> I wanted to revisit that protocol, to see how we could improve it and >>> fix its privacy drawbacks, while preserving the nice UX improvements >>> that it brings. >>> >>> I have prepared a gist with three different designs that achieve those >>> goals [2]. I'm attaching the contents of that gist below. I'd like to >>> turn it into a bLIP once I collect enough feedback from the community. >>> >>> I don't think we should select and implement all three options. They >>> show that we have a large enough design space, but I think we should >>> aim for simplicity of implementation and deployment. My personal choice >>> would be to do options 1 and 3: clients (mobile wallets) would first >>> make a DNS request corresponding to option 3, and if that fails, they >>> would fallback to option 1. Domain owners would implement only one of >>> those two options, depending on their DNS capabilities. >>> >>> Curious to hear your thoughts! >>> >>> Many thanks to Rusty and Matt who reviewed early drafts of that gist. >>> >>> [1] https://lightningaddress.com/ >>> [2] https://gist.github.com/t-bast/78fd797a7da570d293a8663908d3339b >>> >>> # Lightning Address >>> >>> [Lightning Address](https://lightningaddress.com/) is a very popular >>> protocol that brings UX improvements that users love. >>> We'd like to provide those UX benefits without its privacy and >>> security drawbacks. >>> >>> ## Issues with the current lightning address protocol >>> >>> As described >>> [here](https://github.com/andrerfneves/lightning-address/blob/master/README.md), >>> the lightning address protocol requires payment senders to make an >>> HTTP request to the recipient's domain owner. >>> This has some inconvenient side effects: >>> >>> 1. The payment sender reveals their IP address to the recipient's >>> domain owner, who knows both the sender and the recipient. >>> 2. The domain owner can swap invoices to steal some of the payment. >>> 3. It introduces a dependency on DNS servers and the need for an >>> HTTP stack on the sender side. >>> >>> We can do better and fix or mitigate some of these issues, without >>> compromising on UX. >>> We need two somewhat distinct mechanisms: >>> >>> 1. A way to privately obtain the `node_id` associated with a given >>> domain. >>> 2. A way to privately contact that domain to obtain the recipient's >>> payment details. >>> >>> ## User story >>> >>> Alice wants to pay `bob at domain.com` without any other prior >>> information. >>> She doesn't want to reveal: >>> >>> * her identity to Bob (payment sender privacy) >>> * her identity to the manager of `domain.com ` >>> (payment sender privacy) >>> * the fact that she wants to pay `bob at domain.com` to her LSP >>> (payment recipient privacy) >>> >>> ## Option 1: use DNS records to link domains to nodes >>> >>> A first proposal would be to use a DNS record to obtain the >>> `node_id` associated with a given domain. >>> >>> ### Obtain a blinded path to the node associated with a domain >>> >>> Domain owners add a DNS `TXT` record for their domain containing a >>> blinded path to their node. >>> They may include an empty path if they wish to directly reveal their >>> `node_id`. >>> >>> | hostname?????????????? | record type | value?????????????? | >>> TTL???????? | >>> |------------------------|-------------|---------------------|-------------| >>> >>> | _lnaddress.domain.com . | TXT???????? >>> | path: | path expiry | >>> >>> Alice can then make a DNS query to obtain that blinded path. >>> >>> ```text >>> Alice DNS server >>> | | >>> ?????? | dig TXT _lnaddress.domain.com | >>> |-------------------------------------------------------------------->| >>> ?????? |????????????? _lnaddress.domain.com >>> . IN TXT "path:c3056fb73aa623..." | >>> |<--------------------------------------------------------------------| >>> ``` >>> >>> :question: What encoding should we use for the blinded path option? >>> Bech32m with the `lnp` prefix? >>> >>> :warning: Alice should query that DNS record using >>> [DoH](https://datatracker.ietf.org/doc/html/rfc8484) for privacy. >>> She should also query multiple DoH servers to protect from malicious >>> ones. >>> >>> :warning: Alice should check the AD flag is correctly set (DNSSEC). >>> >>> ### Obtain a Bolt 12 offer from the recipient >>> >>> Now that Alice has a way to reach the node that owns Bob's domain, >>> she needs to contact them to obtain a Bolt 12 offer from Bob. >>> We use an `onion_message` for that, which has the following benefits: >>> >>> * Alice doesn't reveal her identity (IP address or `node_id`) to Bob >>> or Bob's domain >>> * Alice doesn't reveal Bob's identity (IP address or `node_id`) to >>> her LSP >>> * Alice doesn't even need to know the IP address for Bob's domain's >>> lightning node >>> >>> ```text >>> ???? Alice????????????????????????? Alice's >>> LSP????????????????????????? Bob's LSP??????????????????????????? Bob >>> ?????? | | |???????????????????????????????? | >>> ?????? |????????? onion_message | |???????????????????????????????? | >>> ?????? |-------------------------------->| onion_message??????????? >>> |???????????????????????????????? | >>> ?????? |???????????????????????????????? |? get_offer_from >>> =bob at domain.com?? |???????????????????????????????? | >>> ?????? | |---------------------------------->| | >>> ?????? | |?????????????????????????????????? | wake_up???????????? | >>> ?????? | | |-------------------------------->| >>> ?????? | |?????????????????????????????????? | offer????????????? | >>> ?????? | | |<--------------------------------| >>> ?????? |???????????????????????????????? | onion_message??????????? >>> |???????????????????????????????? | >>> ?????? | |<----------------------------------| | >>> ?????? |????????? onion_message | |???????????????????????????????? | >>> ?????? |?????? bob's bolt12 offer | |???????????????????????????????? | >>> ?????? |?????? bob's LSP signature | >>> |???????????????????????????????? | >>> |<--------------------------------| |???????????????????????????????? | >>> ``` >>> >>> Note that Alice cannot verify that the offer she receives is really >>> from Bob: she has to TOFU (trust on first use). >>> But that's something we fundamentally cannot fix if the only >>> information Alice has is `bob at domain.com`. >>> However, Alice obtains a signed statement from Bob's LSP that >>> attests that `bob at domain.com` is associated with the Bolt12 offer >>> she receives. >>> If she later discovers that this was invalid, she can publish that >>> proof to show the world that Bob's LSP is malicious. >>> >>> Otherwise, since there needs to be some out-of-band communication >>> where the recipient advertizes their lightning address (e.g. on >>> social media), some kind of verification code could be attached >>> (hash of the `node_id`?). >>> The sender's wallet could optionally add a manual verification step >>> of that verification code. >>> This would only need to be done once, since Alice can then reuse the >>> same offer to fetch new invoices. >>> >>> ### Advantages and drawbacks >>> >>> The main advantage of this proposal is that it is simple, >>> inexpensive and relies on standard mechanisms. >>> Its drawback is that domain owners need to be able to publish DNS >>> `TXT` records, but that is widely supported. >>> >>> ## Option 2: use `node_announcement` to link nodes to specific domains >>> >>> This proposal is only based on the lightning network, without any >>> dependency on DNS or HTTP stacks (apart from certificate validation). >>> >>> ### Obtain the `node_id` associated with a domain >>> >>> We add fields to `node_announcement` to let nodes advertize which >>> domains they own. >>> Those fields would typically contain a signature of the `node_id` >>> using the private key for the corresponding domain TLS certificate, >>> along with its certificate chain. >>> Alice can then simply sync `node_announcement`s that contain domain >>> links with her LSP: >>> >>> ```text >>> ???? Alice???????????????????????????????????????????? LSP >>> ?????? |??????????????????????????????????????????????? | >>> ?????? |????????????????? node_announcement(foobar.com >>> ) | >>> ?????? |<-----------------------------------------------| >>> ?????? |????????????????? node_announcement(domain.xyz >>> ) | >>> ?????? |<-----------------------------------------------| >>> ?????? |??????????????????? node_announcement(ln.stuff) | >>> ?????? |<-----------------------------------------------| >>> ?????? |??????????????????????????????????????????? ... | >>> ?????? |<-----------------------------------------------| >>> ``` >>> >>> ### Obtain a Bolt 12 offer from the recipient >>> >>> This uses exactly the same onion message mechanism as the previous >>> proposal. >>> >>> ### Advantages and drawbacks >>> >>> The main advantage of this proposal is that it relies entirely on >>> lightning protocol messages. >>> Its drawback is that Alice needs to sync some `node_announcement`s >>> to obtain the domain owner's `node_id`. >>> Alice also needs to validate the certificate chain, which is old >>> school annoying crypto. >>> It also doesn't allow domain owners to keep their `node_id` private >>> (which may be useful for small community-based nodes). >>> >>> ## Option 3: use DNS records to directly store Bolt 12 offers >>> >>> Another option would be to make domain owners create one DNS `TXT` >>> record for each of their user, directly containing their Bolt 12 offer: >>> >>> | hostname?????????????????? | record type | value?????????????? | >>> TTL????????? | >>> |----------------------------|-------------|---------------------|--------------| >>> >>> | bob._lnaddress.domain.com . | >>> TXT???????? | lno1qqx2n6mw2fh2... | offer expiry | >>> >>> ```text >>> Alice DNS server >>> | | >>> ?????? | dig TXT bob._lnaddress.domain.com >>> | >>> |-------------------------------------------------------------------->| >>> ?????? |???????????? bob._lnaddress.domain.com >>> . IN TXT "lno1qqx2n6mw2fh2..." | >>> |<--------------------------------------------------------------------| >>> ``` >>> >>> :warning: Alice should query that DNS record using >>> [DoH](https://datatracker.ietf.org/doc/html/rfc8484) for privacy. >>> She should also query multiple DoH servers to protect from malicious >>> ones. >>> >>> :warning: Alice should check the AD flag is correctly set (DNSSEC). >>> >>> ### Advantages and drawbacks >>> >>> The main advantage of this proposal is that it is straightforward >>> for the sender and doesn't require any addition to the lightning >>> protocol. >>> >>> There are some drawbacks though, mostly for the domain owner, >>> because they will need to create a lot of DNS records (one per user). >>> If they're using a cloud provider, there will be limitations in the >>> number of records they are allowed to create. >>> They may not have programmatic access to perform that operation >>> automatically (when a user creates their lightning address). >>> Cheers, >>> Bastien >>> >>> >>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: