Hi, Aron
Continue the discussion, For the question, "- When an issuance request is processed, all 7.5k Ethereum nodes will execute the smart contract. The paper is unclear on whether the Oracle will forward all of those requests to the origin domain, or will make only a single request and then cache the result. If the former, that's a nice DDoS attack. If the latter, that's significantly more complex behavior for the attesting entities to audit." I think only one request should be forwarded to the Oracle. It can be done by submitting the request to the smart contract deployed by the oracle. And oracle will fetch the request from its smart contract and fetch the results from the web server, and later on submit verification request to the certificate issuing contract. To simplify the problem, I think we can consider the http-01 challenge first. Best regards. Haiguang ________________________________ From: Wang Haiguang Sent: Thursday, 9 November 2023 7:23:52 AM To: Aaron Gable Cc: [email protected] Subject: Re: [Acme] Decentralized the ACME Hi, Aron Thanks very much for your comments. We have also considered the cost of issuing certificates. As we all know, one Ether coin is today around 1900 USDs. Definitely we do not want to deploy such a decentralized ACME contract on Ethereum blockchain. There are many different blockchains today and some of them quite cheap in transaction fees. These blockchain with cheap transaction fees support smart contract too. Beside that, we can also consider consortium blockchains, which can have fewer nodes and the cost and transaction speed could be much faster and cheaper. Regarding the revocation, I think we can either issue a certificates with short lives or we can implement a revocation scheme within the smart contract through voting. Voting may involve some complexity, some design might be necessary. For the Oracle part, as its main functionality is to do the off-chain verification. The work is much simpler than maintaining a CA. To be frankly saying, I am not very sure about this point, maybe I have overlooked the complexity on this. Regarding the issue of browser verifying certificate over blockchain record, it is similar to the OCSP or CT we used today. And also, for the same website, the browser does not need to verify it for every https request. The browser might need to visit the blockchain for certificate verification for the first time it receives such certificate. My intention here is to let the experts in this group to notice that there is some different thinkings on the design and implementation of ACME. Although it is from academic, it does make the CA operation and management more transparent and trustworthy. We may consider its merit and shortcomings together. Best regards. Haiguang ________________________________ From: Aaron Gable <[email protected]> Sent: Thursday, 9 November 2023 1:39:05 AM To: Wang Haiguang Cc: [email protected] Subject: Re: [Acme] Decentralized the ACME Hi Wang, Thanks for your interest in ACME, and for sharing this paper with us. Unfortunately, I think the ideas presented in the paper are undesirable for most website operators, concerning from an implementation perspective, and significantly exceed the scope of this working group. First and most obviously, the transactions to issue a certificate with a single short DNS Name cost about $5 USD in gas. These costs go up both with the length of the DNS name and the number of DNS Names in the certificate; a median certificate with "myrestaurantname.com<http://myrestaurantname.com>" and "www.myrestaurantname.com<http://www.myrestaurantname.com>" appears to cost $15. Worse, it costs money (about $1) to revoke a certificate: this is unacceptable, as revocation is critical for the security model of the Web PKI. Second, the proposal raises many implementation concerns for me. In no particular order: - Only the original issuer (wallet) can revoke a certificate. There's no mechanism for a security researcher who discovers a compromised private key to revoke all certificates with that key. - The description of the Oracle, which mediates between the smart contract running on the Ethereum Virtual Machine and the open internet, seems identical to that of a "Delegated Registration Authority" in the CA/BF Baseline Requirements: i.e. it is the entity which actually performs domain control validation procedures on behalf of the Certification Authority. Those BRs place significant requirements on the operation of an RA, and for good reason: it's the most critical part of CA operations, second only to protecting their private keys. The paper gives no description of how the Oracle's behavior will be monitored, only that "a group of non-cooperating entities can all attest to it". - The number of entities attesting to the Oracle's good behavior also increases the gas cost of issuance, so there are bad incentives here -- less trustworthy certificates cost less to issue. - When an issuance request is processed, all 7.5k Ethereum nodes will execute the smart contract. The paper is unclear on whether the Oracle will forward all of those requests to the origin domain, or will make only a single request and then cache the result. If the former, that's a nice DDoS attack. If the latter, that's significantly more complex behavior for the attesting entities to audit. - What happens when I issue a certificate right before the Ethereum blockchain hard-forks again in a desperate attempt to recover from another gaping security bug? Third, the paper proposes not just a new issuance mechanism, but a new validation mechanism: the browser gets the public key from the blockchain and trusts the server certificate directly, rather than having a list of trusted roots and performing chain-building for validation. This is outside the scope of this working group, and my personal opinion is that this sinks the entire proposal as mainstream browsers will never implement this. Fourth and perhaps most damning, the paper seems to completely misunderstand the ACME protocol. It states repeatedly that it "imitates" the ACME protocol, but as far as I can tell that imitation exists solely in the fact that a) it is automated, and b) it uses a method similar to (but not identical to!) ACME's HTTP-01 for domain control validation. The domain owner does not use any of the ACME protocol's defined request or response methods to communicate with the smart contract; the oracle does not actually use HTTP-01 to perform DCV; and there is no mention made of other aspects of ACME such as DNS-01, wildcard validation, CAA account and method binding, ACME STAR, or others. This paper resembles ACME in name only. Finally, the authors state that the problem they're trying to solve is that people have to trust CAs. But instead they transfer all of this trust simply to the Oracle, and hand-wave the trust problem there. One of their proposed solutions even involves a number of corporations using their own inherently-trusted keys to sign attestations on behalf of the Oracle. That sure sounds like trusting authorities to me! So I do not believe this paper even comes close to solving the problem it sets out to solve, and is not worth pursuing further. Aaron On Wed, Nov 8, 2023 at 5:41 AM Wang Haiguang <[email protected]<mailto:[email protected]>> wrote: Hello, everyone My name is Haiguang Wang from Huawei. I am interested in the networking and security protocols research. I have attended IETF meeting since year 2017 and have followed the work in ACME group for sometime. Last year we have come across a research paper "A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI". Following is the information of the paper: E. F. Kfoury, D. Khoury, A. AlSabeh, J. Gomez, J. Crichigno and E. Bou-Harb, "A Blockchain-based Method for Decentralizing the ACME Protocol to Enhance Trust in PKI," 2020 43rd International Conference on Telecommunications and Signal Processing (TSP), Milan, Italy, 2020, pp. 461-465, doi: 10.1109/TSP49548.2020.9163555. We have studied the scheme for sometime but not sure whether it is a good direction for ACME or not. The scheme implements the ACME in smart contract and make the whole procedure of certificate more transparent, not only in CT log, but also in the certificate issuing and management. We would like to hear comments from the experts in this group. Best regards. Haiguang Wang Huawei International Pte. Ltd. _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
