CIP-0043? | Address Resolution and Validation through DNS and HTTP #319
Conversation
HeptaSean
changed the title
There was a problem hiding this comment.
I think this is workable & well thought out. People at all technical levels will be intrigued by the idea of spoofing this system, e.g. though the possible exploitability of Unsolicited Domain Tokens (though from my level it sounds like your qualification of the risk is good enough), so I'd expect there will be good participation also on the Cardano Forum about this (CIP Draft: Domain Validation for Cardano Addresses):
There was a problem hiding this comment.
This proposal was discussed favourably at CIP Editors' Meeting # 53 today. I mentioned that I'd read through the proposal already (shortly after submission) and found it to be well explained, technically justifiable, and well precedented both in the crypto field (with equivalents on Ethereum) and existing Internet convention (e.g. CAA records for HTTPS cert validation). The editors & guests were also referred to the forum link above where we can see nobody has (yet) refuted or poked any serious holes in this method.
I think any possible exploitability due to Unsolicited Domain Tokens might be no worse than the exploitability of a bare address that can only be validated manually. It's usually impossible to provide additional functionality without it somehow being usable to someone's disadvantage, so it wouldn't make sense to disqualify this proposal for that reason alone. In any case this risk is well addressed in the CIP text, so those using this standard might take steps to prevent exploitation and/or set users' expectations accordingly.
So after a detailed technical read & review from another editor I feel this can be merged as draft, either directly on GitHub or at the next CIP Editors' Meeting.
Thank you so much for your efforts! They are much appreciated. (I was just going to ask, where I find other reviewers, but I see you already have invited.) |
In response to https://forum.cardano.org/t/cip-draft-domain-validation-for-cardano-addresses/106328/9: Clarify domain tokens not being proofs of ownership of domains and, hence, policies for them not needing to be complicated.
To allow (sub)domains longer than 64 bytes, allow the array of strings workaround known from other metadata standards.
Methods are considered to be used even if their results are malformed or empty.
In response to https://forum.cardano.org/t/cip-draft-domain-validation-for-cardano-addresses/106328/9: Lots of domain tokens – especially unsolicited ones – and the queries done because of them could stall an application. Advice to do the queries asynchronously/concurrently added.
HeptaSean
force-pushed
the
domainvalidation
branch
from
04fd93c
to
4f9bbf1
Compare
|
Just added a few clarifications. Only real change is that domains longer than 64 bytes are allowed to be done now by arrays of strings (as already done in other metadata CIPs). 3638814 Some clarifications due to points raised in https://forum.cardano.org/t/cip-draft-domain-validation-for-cardano-addresses/106328/9:
Other than that I have formulated the corner cases of empty or malformed TXT and JSON data in validation a bit clearer in 891932a. They are considered as being present and, thus, have to be corrected for the intersection not to be empty. 4f9bbf1 just adds a few comments to the example execution with the reference implementation. |
|
thanks @HeptaSean - I can see this incorporates feedback from the Cardano forum, e.g. about conflict resolution. The additional detail & clarifications are all helpful. Since this CIP is up for Review (i.e. before merge), would you be able to come to the next CIP Editors Meeting (# 54, in <2 days) to help get consensus in favour of merging this? https://discord.gg/gDabJZmd (p.s. our comments crossed each other again, i.e. I wrote this without yet seeing the posting above 😖) |
Unfortunately, this is in the middle of the work day, but I'll see what I can do. |
KtorZ
changed the title
|
I see you also changed the title. Could we settle for "Address Resolution and Validation through DNS and HTTP" or "Address Validation through DNS and HTTP"? I think the validation part is pretty important.
The "block hash + slot number + transaction index" pointer could only be employed on the DNS/HTTP side of things. On the token side of things, it would have to be in metadata and we are doing that to find the metadata in the first place. For the use case starting from a domain, this would work. We could probably even discard the token completely and only use transaction metadata (akin to Catalyst registrations). But for the use case starting from an address and looking if one or more domains are associated with it, there is no easy solution. That's why I settled with a token and the metadata found in a way that is already widely used for NFTs (although it needs at least With respect to the risk of spoofing: I really don't think that is a big problem, here. I should add a note at the paragraph about the policy that it should not allow third parties to mint, which is not a relevant restriction, since the token is only a data holder/pointer in this CIP, anyway.
Looking forward to your review. Would @michaelpj perhaps be so kind to have a look. His comments on other metadata CIPs were gold. |
KtorZ
changed the title
|
I am in the progress of formulating a similar CIP, maybe these can be brought together. But it would be another workflow, also includes signing. |
Sure. Always better than competing. By what communication means would you be available?
If it doesn't get too complicated, gladly. I thought about signing on both ends. On the domain end – with the TLS keys for that domain, I deemed it not worthwhile, since a HTTPS connection is already protected by the very same keys. And it would have to be updated quite often, when they change (every 90 days for Let's Encrypt, for example). On the Cardano end, it would alleviate some of the drawbacks of my proposal. Sure. I'd say my main requirement is that it could be done by the owner of a domain with medium knowledge in server administration and Cardano without a third party/authority (perhaps with the help of functionality built into wallet apps). |
|
To Dos from the CIP Editors' Meeting (as far as I recollect):
|
|
The idea of requiring bidirectional attestation to avoid either side being fraudulent is nice. At a high-level, this approach reminds me of Keybase's "proof" system, where you use the ability to post a proof in a particular location as evidence that the issuer of the proof controls that location. In our case we want to link domains and Cardano addresses. Clearly we need both directions: it's no good if fraudulent domains can claim to own addresses, and no good if fraudulent addresses can claim to own domains. The tricky part of this to me seems to be the publishing of the proof/claim associated with the address. Since in Cardano anyone can make an output at any address, merely publishing something in an output locked with an address tells us very little. My understanding of this proposal is that it basically gives up on trying to make the address->domain direction secure. I'm a little unconvinced by the argument:
If this is true, then what's the point of the tokens in the first place? If users are interacting with a server and need to know what address it wants them to send money to... it can just tell them. No need for this whole scheme. And I think the risk is understated here. This system makes it very easy for someone to post a fraudulent claim linking an address to a domain. If this proposal becomes widely adopted, then this could be an attack vector. The situation is quite similar to #299 in that regard, and in particular the situation is worst when the attacked party doesn't even know or care about this CIP. So it potentially makes unsuspecting third parties less secure, which seems bad. So I think this proposal would be much better if it had some way to securely post proofs in the address->domain direction. The idea of associating the proof with a token could work, if the forging conditions of the token establish something. The existence of a particular token can serve as evidence that it was produced in a certain way... One fundamental problem is what the "relation" that this proposal establishes is, and I think we should be clear on that. Posting a proof at a domain shows that you control or own the domain. What is this system trying to establish about an address? The concept of "controlling" or "owning" an address is under-specified. Does it mean "being able to spend from it"? In the case of public key addresses, arguably this is good enough, but for other addresses like script addresses, even if you can prove that you were able to spend from it at one time, that doesn't prove that you would be able to spend from it at another time. I think this is quite serious but not that surprising: this has been a common problem for the various metadata proposals, because they want the metadata to be posted by the "owner" or "controller" of the address, but this is under-specified. And indeed the domain associated with an address is... metadata! So it's not surprising that it has similar problems. I think the metadata argument suggests that it's going to be hard to make this proposal secure. Maybe the insecure version is still useful and not an attack vector against the innocent, but I think it's unclear. The reverse direction seems fine, if less exciting: having some kind of standard lookup for where to list addresses that you claim to control seems okay. |
|
Thank you, @michaelpj, for the detailed review!
It is needed to allow wallet apps and explorers to discover the domain if they only have the address, akin, for example, to Cardanoscan now showing the first ADA handle it finds as a title for the address: https://cardanoscan.io/address/addr1qyh72hvvrurjvddx4gq37jd2fzyef8scz9cwcyc90dffq0xxllh3nc5r82ujj36fy9zh0gryqvqy7r3ejd2h2kgsvryswhjr9q
…, but I agree now that this would be much better. If I understood @gitmachtl correctly, the signing in his planned similar CIP would also go in that direction.
My first idea would have been to require the policy of the domain token to have the payment key of the address as signer. Would still be somehow lean. But that would completely exclude script addresses from being used with this CIP. But maybe that's even the right way given that “controlling” and “owning” is hard to define for scripts. |
Right, so discoverability is important. Maybe it's worth it on its own, I don't know! But I think it should be called out very clearly that this is different in kind to what we are getting in the other direction. You have two things: a way of listing verifiable proofs about what addresses domains claim to be associated with, and a totally unverifiable, spoofable-by-anyone directory of mappings in the opposite direction. Additionally, if you don't get any security from keeping this information on the chain, then question is: why use the chain? At that point we're just using Cardano as a) a very expensive database, b) a point of coordination about which data store to use. I'm generally of the opinion that a) is bad design, but b) might be valuable. But I think that we should seriously consider whether the proposal would be worse with e.g. an off-chain directory for the address->domain lookup.
This is fundamentally different, though, since ADA handle presumably stop people from minting multiple duplicate handles, and so the existence of the token does tell you something!
Sounds like we need some requirements analysis :) I note that this CIP is pretty light on motivation and use cases. Always good to know what our users actually want and need! |
Agreed. … or rework it in a way that gives comparable security in the other direction. I tend to go in the direction of requiring the policy of the domain token to be derived from the payment (and stake) key hash of the address. That is easily checked by clients and gives us the guarantee that the domain token can only be minted by the entity controlling the address. It excludes scripts for the payment as well as the stake part, but for those “owner” is not well-defined, anyway, as you keep saying in this and other CIPs. And arguably, if they are really decentralised, it would be more valuable if they point to their off-chain code – maybe somewhere on IPFS – than to a specific domain. But that would be a totally different CIP … if at all.
I'm not a big fan of off-chain solutions for something like this. Someone has to host the directory, we have a single point of failure there, wallet apps would have to continuously query it for the addresses they encounter. A token-based solution can be queried decentralised at the next cardano-db-sync instance. … and I would make the point that the rather small metadata put on chain in this CIP is much more worth it than all the questionable token and NFT metadata already on it.
Different, yes, but the unsolicited token problem would be the same. In the other direction, it gives you uniqueness, which is a bit more, but only the fact that someone paid 10 ADA for that name, which arguably is a bit less than domain validation.
Hmpf. I thought that I was already quite good compared to the existing CIPs, but you are right. Rewrite might take a bit, though. |
... which is one of my major problems with most CIPs :) it's really important for us to be very clear about what we're trying to do so we know if a design is good or not before we jump on it! |
|
Hey @HeptaSean, during a internal discussion this week it was raised that perhaps DIDs through Atala Prism could applied to create a similar solution. Has this been considered? |
The concepts of a DID document are related. DID documents associates metadata like a service endpoint with a decentralized ID (DID) so that the cryptographic controller of the DID can provide some associated-identifier/connection/communication metadata for the DID. The service that 'resolves' a DID to a DID Document is called a Universal Resolver which hosts the drivers for each DID method https://github.com/decentralized-identity/universal-resolver. |
I haven't considered it for this CIP. It's a totally different use case. This CIP is about relating Cardano addresses with DNS domains/websites with techniques that have been used for years. There is no SSI/DID to be seen anywhere, there. Of course, there could be another CIP relating addresses or domains or both with DIDs, even with Atala Prism DIDs (if they publish documentation – it's all gatekeeped exclusively for “pioneers” up to now). But that won't be by me. I don't believe that SSI on blockchains, especially on cryptocurrency blockchains is a valuable application. Not at all. |
There was a problem hiding this comment.
Firstly, thanks for putting (visible) efforts into this proposal, with detailed sections and reference implementation.
I did leave a few inline comments while reviewing but I'd like to put emphasis on one particular point (which I think echoes a bit @michaelpj's response): the proposal falls a bit short when it comes to the address -> domain side; for both the motivation and the specification.
The motivation from domain to address is pretty obvious and, the only arguments I could find to be brought forward regarding the address -> domain direction was the 'discoverability' of that relation by wallets and its 'transferability'. However, I can't fully grasp my head around what a token really brings to the table here (or how this is indeed the easiest way to achieve this relation).
In particular, the proposal seems to suggest that the token must live under the specific address it identifies -- which is generally a not-so-practical requirement for wallets who prefer to manage tokens freely. Having said that, the discoverability process that was given involved looking up past transactions for specific mint events carrying metadata. Since wallets do discover transaction history anyway, the token seems redundant to me. You could have the same discoverability mechanism (with the same level of security) by letting wallets discover any transaction in their history that have the appropriate metadata. The relationship is however a bit weak and implies that the user already knows of the domain; so why not simply provide it explicitly to the wallet?
I'd like to stress this last bit and, something @michaelpj also said earlier: what additional security does the publication on-chain provides here? If none, then arguably, the same process could likely exists off-chain. Wallets can leave the list of "accepted domains" open for users to complete, with possibly a preset of well-known entities or projects that have been somewhat verified by the wallet provider. I fail to see how the on-chain token as proposed here currently brings any additional protection than this.
If on-chain discoverability (without any explicit user action) is a really a desirable feature, we could imagine enriching transactions from addresses associated with a domain with explicit metadata informing about this very piece of information. The information in that sense becomes local to the transaction and are purely for the recipient (since the sender would already known they own the associated domain). Imagine a "Send as foo.cardano.org" button in wallets, allowing senders to send with a proof that they own the associated domain.
| --- | ||
|
|
||
| ## Abstract | ||
| This Cardano Improvement Proposal (CIP) specifies a process, by which a |
There was a problem hiding this comment.
| This Cardano Improvement Proposal (CIP) specifies a process, by which a | |
| This document specifies a process, by which a |
| relation between Cardano addresses and Domain Name System (DNS) domains can | ||
| be established. | ||
| Such a relation can be used in both directions: | ||
| Wallet apps can allow to discover addresses based on given domains and they |
There was a problem hiding this comment.
| Wallet apps can allow to discover addresses based on given domains and they | |
| Wallet apps can discover addresses based on given domains and they |
| In the direction from a Cardano address to a DNS domain, the relation is | ||
| established by Cardano native tokens with an asset name of `Domain` | ||
| (`446f6d61696e` as hexadecimal bytes) and metadata attached to them in | ||
| their minting transactions. |
There was a problem hiding this comment.
Perhaps consider using CIP-0067 for this.
| their minting transactions. | ||
|
|
||
| These tokens are meant to be minted by the owner of the address(es) and the | ||
| domain(s) – or someone acting on their behalf. |
There was a problem hiding this comment.
How is this enforced? Shall the policy be explicitly defined by this proposal so that users of this proposal can share a common set of assumptions / invariants w.r.t the rules governing a specific token?
| token to the target address(es). | ||
|
|
||
| If, however, `Domain` tokens with different policy IDs are found at an | ||
| address, the metadata found for all of them, must be taken into account. |
There was a problem hiding this comment.
How should multiple metadata "be taken into account"? Are clients expected to "merge" them? Show them separately?
It seems therefore relatively easy for anyone to provide any kind of metadata for a chosen domain -- and thus, for any address to "claim" a domain. Isn't that a problem?
| The JSON document at this URL has the following structure: | ||
| ```json | ||
| [ { "address": "addr1…", | ||
| "Comment": "<Purpose of this address>" }, |
There was a problem hiding this comment.
| "Comment": "<Purpose of this address>" }, | |
| "comment": "<Purpose of this address>" }, |
| [ { "address": "addr1…", | ||
| "Comment": "<Purpose of this address>" }, | ||
| { "address": "addr1…", | ||
| "Comment": "<Purpose of this address>" } ] |
There was a problem hiding this comment.
| "Comment": "<Purpose of this address>" } ] | |
| "comment": "<Purpose of this address>" } ] |
| "Comment": "<Purpose of this address>" } ] | ||
| ``` | ||
| It is a list of JSON objects, which must have an `"address"` field and may | ||
| have arbitrary additional fields. |
There was a problem hiding this comment.
Consider providing a simple JSON-schema in annex to cover this structure.
| For a Cardano address, all related domains are found by: | ||
| * All tokens with an asset name of `Domain` (`446f6d61696e`) that are | ||
| currently at an unspent transaction output (UTxO) of that address are | ||
| searched. |
There was a problem hiding this comment.
How do we ensure that tokens remain associated with the address they're supposed to represent? Is it a responsibility of wallets to carry tokens with the address as UTxOs gets spent? Shall wallets leave UTxOs carrying domain tokens "untouched"? Or shall the token policy itself checks for these requirements upon spending from the address?
| * If both methods are used, the intersection of HTTP(S)-related addresses | ||
| and DNS-related addresses is the set of related addresses. | ||
| If only one method is used, its result is the set of related addresses. | ||
| If none of the methods is used, the set of related addresses is empty. |
There was a problem hiding this comment.
I always tend to have reserves on processes / APIs which offer two redundant ways of achieving the same goal. Is there any rationale that justifies the use of both TXT records and well-known metadata? Why not only one? Is there any advantage to use one or the other depending on the use case (would love to see answers to those question in the Rationale section).
Having two methods, as such, seems to only have drawbacks to me since:
(a) For consumers downstream, it isn't possible to really chose one method. They would necessarily have to fetch both the TXT record and the JSON metadata, and compute the intersection. It's not like one is defined to be a fallback of the other.
(b) For DNS owners, they would also likely end up providing both, with redundant information and with the risk of getting data discrepancy between the two should they forget to update both documents.
KtorZ
added
the
State: Waiting for Author
KtorZ
added
Category: Tools
There was a problem hiding this comment.
I think that there are still some lingering questions regarding this one but otherwise a couple of "TODOs" to move this closer to being at least merged as a proposed CIP rather than staying as a forever pull request:
- Address lingering questions and typos
- Update document format to match current header and content standards specified in CIP-0001
- Remove the reference implementation to a separate/remote repository so that it does not require CIP Editor approval for modifications or changes
This is, otherwise, an interesting proposal particularly in terms of address discovery on behalf of the owner of a domain and could be particularly useful for at least identifying the "trusted" addresses of things like dApps, etc.
|
I think we have confirmed a
|
rphair
added
State: Likely Abandoned
This CIP specifies a process, by which a relation between Cardano addresses and DNS domains can be established.
Such a relation can be used in both directions: Wallet apps can allow to discover addresses based on given domains and they can also annotate given addresses with domains found for them.
see rendered Markdown