Consider DANE as an alternative to Certificate Authority

[pinheadmz]

Hi there, I love the lightning address proposal, I just have an idea to add.

This proposal is similar to BIP70 in that it relies on out-of-band authentication based on DNS and Certificate Authority systems. I think this external authority was one of the reasons the Bitcoin community was uncomfortable with BIP70, which was eventually removed from Bitcoin Core in bitcoin/bitcoin#15584

I contribute to an altcoin project with the goal of securing an alternative DNS root zone on its PoW blockchain. We have also embraced the useage of the /.well-known pattern for serving wallet addresses (HIP-0002) but since no Certificate Authorities recognize our root zone, we use DANE to anchor all TLS connections.

DANE is controversial to legacy internet engineers because it just sort of trades one central-authoritarian security model (CA) for another (DNS). However by using blockchain-based domain naming systems like Namecoin, Handshake and others, we believe DANE has a new life and we can achieve secure http connections using TLS but without any central authority at all.

Anyway! I just wanted to put that idea on the table, I'm happy to help you develop it. I have been running LND since it was available on mainnet, connected to a local Bitcoin Core full node. Later on this month I'll try experimenting with lightning-address using a Handshake domain, secured by DANE ;-)

[andrerfneves]

This sounds very interesting indeed. I look forward to seeing whatever you come up 🚀

[Falci]

I have DANE proper configured on my personal website, as well as lightning address.
This may be, so far, the only website with both features.
If anyone wants to explore more: dane@falci.me

[andrerfneves]

@Falci are you able to point to the right place if I wanted to test using it through DANE? Not too familiar with it myself.

[Falci]

When we make an https request, programmatically or via browser, the SSL is automatically verified.
I wish DANE verification could be done that simple.

But basically, the client making the request needs to verify the SSL's fingerprints against a DNS record.

To check the DNS record (secured by DNSSEC):

dig _443._tcp.falci.me TLSA +dnssec +short
3 1 1 2E15066F49B8359A4CF5A18F19DEE2C9F58D988186256B5BA99DDAFE EC614D7B
TLSA 13 4 3600 20211125090350 20211123070350 34505 falci.me. MnFXXpJRJ7UiUlxCp87VFzLTORuJS0n07/47SXYPYi+lyil4gmti83vB sP2bKjSdICteXPlzMvhbIJCSs49zfw==

And to retrieve the cert's fingerprint:

echo | openssl s_client -showcerts -servername falci.me -connect falci.me:443 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin  -outform der | openssl dgst -sha256
2e15066f49b8359a4cf5a18f19dee2c9f58d988186256b5ba99ddafeec614d7b

Useful links:
https://www.huque.com/bin/danecheck
https://linux.die.net/man/1/ldns-dane
https://github.com/handshake-org/hdns