{"action":"created","issue":{"url":"https://api.github.com/repos/ipfs/notes/issues/181","repository_url":"https://api.github.com/repos/ipfs/notes","labels_url":"https://api.github.com/repos/ipfs/notes/issues/181/labels{/name}","comments_url":"https://api.github.com/repos/ipfs/notes/issues/181/comments","events_url":"https://api.github.com/repos/ipfs/notes/issues/181/events","html_url":"https://github.com/ipfs/notes/issues/181","id":184674511,"number":181,"title":"Extending IPNS to optionally resolve to plain HTTPS hosts through TLS certificate PK hashes and handshake verification","user":{"login":"rotemdan","id":8589488,"avatar_url":"https://avatars.githubusercontent.com/u/8589488?v=3","gravatar_id":"","url":"https://api.github.com/users/rotemdan","html_url":"https://github.com/rotemdan","followers_url":"https://api.github.com/users/rotemdan/followers","following_url":"https://api.github.com/users/rotemdan/following{/other_user}","gists_url":"https://api.github.com/users/rotemdan/gists{/gist_id}","starred_url":"https://api.github.com/users/rotemdan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rotemdan/subscriptions","organizations_url":"https://api.github.com/users/rotemdan/orgs","repos_url":"https://api.github.com/users/rotemdan/repos","events_url":"https://api.github.com/users/rotemdan/events{/privacy}","received_events_url":"https://api.github.com/users/rotemdan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-10-23T06:31:59Z","updated_at":"2016-10-23T13:22:46Z","closed_at":null,"body":"It seems like IPNS could, in theory, provide a rudimentary alternative for DNS, and act as a complement to the plain TLS handshake and HTTP protocol stack (though with some minor modifications):\r\n\r\n1. User creates a self-signed TLS certificate and loads it to an HTTPS server (note: the certificate doesn't have to be associated with any particular 'name' or 'domain' of the conventional form).\r\n2. The certificates' public key is hashed and then used as an IPNS name.\r\n3. The resulting IPNS name resolves to an HTTPS host URL. E.g. https://172.217.21.238:443\r\n4. When the newly defined name association is first transmitted to an IPFS DHT node, it tries to establish a TLS connection to the target address, hashes and verifies the public key within the certificate given during the TLS handshake and then closes the connection. This is only done once.\r\n5. The certificate given by the host would also be verified and hashed at every request made by a client. Otherwise, it would then proceed as a normal HTTPS connection and can use any HTTP protocol stack and even support HTTP/2 as well (or theoretically any protocol that runs on top of TLS).\r\n\r\nMy question is: has this ever been considered as a possible feature of IPFS/IPNS, in some form? are there any special security implications that need to be noted?\r\n\r\nI'm aware of the issue of multiple valid hosts sharing the same certificate (though it seems possible an elegant solution for that could be found). Perhaps more generally I'll ask what are your current views on this direction - of providing a gateway to the more conventional 'mutable' web through the distributed name system (technical issues aside)?\r\n\r\n**Edit**: \r\n\r\nSome points of clarification:\r\n\r\n1. There are two different layers of verification for a hash/host combination. First, the given host _address_ (ip/port combination) is signed by the submitter, so that's the first layer. The second layer is that the host _itself_ is contacted and a TLS handshake performed with it, where the expected PK in the given certificate should match the public key given by the submitter of the IPNS entry (there might be some slight technicalities for securing the signatures for the host address but I'm leaving that for the moment).\r\n2. The certificate doesn't have to be self-signed, and it can actually point to any 'normal' DNS domain. The IPNS system simply doesn't care about what it points to, as long as its public key hashes to the expected value and the TLS handshake to the host succeeds. This means that any 'normal' website can also be submitted to IPNS by its owner.\r\n\r\n**Edit2**: some corrections"},"comment":{"url":"https://api.github.com/repos/ipfs/notes/issues/comments/255588335","html_url":"https://github.com/ipfs/notes/issues/181#issuecomment-255588335","issue_url":"https://api.github.com/repos/ipfs/notes/issues/181","id":255588335,"user":{"login":"rotemdan","id":8589488,"avatar_url":"https://avatars.githubusercontent.com/u/8589488?v=3","gravatar_id":"","url":"https://api.github.com/users/rotemdan","html_url":"https://github.com/rotemdan","followers_url":"https://api.github.com/users/rotemdan/followers","following_url":"https://api.github.com/users/rotemdan/following{/other_user}","gists_url":"https://api.github.com/users/rotemdan/gists{/gist_id}","starred_url":"https://api.github.com/users/rotemdan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rotemdan/subscriptions","organizations_url":"https://api.github.com/users/rotemdan/orgs","repos_url":"https://api.github.com/users/rotemdan/repos","events_url":"https://api.github.com/users/rotemdan/events{/privacy}","received_events_url":"https://api.github.com/users/rotemdan/received_events","type":"User","site_admin":false},"created_at":"2016-10-23T13:22:46Z","updated_at":"2016-10-23T13:22:46Z","body":"**Trying to tackle some technical and other misc issues:**\r\n\r\n_What about when the certificate/PK is changed by the author (I mean - not necessarily due to a compromised key but say, for periodic renewal or for extra security reasons)? will the link be broken forever?_\r\nSolution: A new IPNS entry would be created and the old one could modified to point to it, instead of the concrete host locator. Basically, instead of pointing to an HTTPS host, the old 'hash' would now point to the new hash by resolving to an IPNS locator instead of a host. If the new hash is verified and the author has proved of owning the two public keys by providing the correct signatures then the entry is considered valid. (this redirection can happen several times)\r\n\r\n_What about multiple IPs per PK? failover? round robin?_\r\nThis needs to be investigated further.\r\n\r\n_Why limit just to the proven owner? why not allow everyone to submit these types of IPNS entries as long as they are verifiable through the handshake?_\r\nThere is no fundamental reasons why not actually. Technically a bot could actually go and scan entire DNS registries, contact the hosts, read the certificate's PL and automatically submit it to IPNS to eventually mirror significant parts of the web and update the entries when the addresses and certificates change.\r\n\r\nThe problem has more to do with ensuring good quality, up-to-date records. There is also a problem of opening further vulnerability to various forms of replay, DDoS and other attacks."}}
{"actor":{"display_login":"rotemdan"}}