#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.
- 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.
- 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.
- Will we hit any DNS record length limits with the blinded path or
offer that need to be considered?
## 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:<blinded_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
`b...@domain.com`. However, Alice obtains a signed statement from Bob's
LSP that attests that `b...@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 `b...@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 <http://domain.com>` (payment
sender privacy)
* the fact that she wants to pay `b...@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 <http://lnaddress.domain.com>. | TXT |
path:<blinded_path> | path expiry |
Alice can then make a DNS query to obtain that blinded path.
```text
Alice DNS
server
| |
| dig TXT _lnaddress.domain.com <http://lnaddress.domain.com>
|
|-------------------------------------------------------------------->|
| _lnaddress.domain.com <http://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 =b...@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 `b...@domain.com`.
However, Alice obtains a signed statement from Bob's LSP that attests that
`b...@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 <http://foobar.com>) |
|<-----------------------------------------------|
| node_announcement(domain.xyz <http://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 <http://lnaddress.domain.com>. | TXT |
lno1qqx2n6mw2fh2... | offer expiry |
```text
Alice DNS
server
| |
| dig TXT bob._lnaddress.domain.com <http://lnaddress.domain.com>
|
|-------------------------------------------------------------------->|
| bob._lnaddress.domain.com <http://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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
