Hello Forum,
Does Let's Encrypt plans the use of blockchain for MultiVA domain validation?
Not that I know. But for people not understanding what "use of blockchain for multi-VA validation" means exactly, could you please elaborate about it?
What does it entail?
What currently existing problem does it fix?
7 Likes
Is there anything in the CAB forum on this?
I suspect it would entail some sort of DNS entry to include an authorized blockchain "public" key and then the CA would check for a mutually agreed entry created by that corresponding "private" key in "the blockchain".
[which is, as yet, undefined... What "blockchain"? Who operates it?]
[but I haven't had much sleep... so, I'd take all that with a grain of salt - lol]
4 Likes
Baseline Requirement when I search for block, the word shows up once on Page 27 of Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.8.6 CA/Browser Forum14 December, 2022 document.
"Reserved IP Address: An IPv4 or IPv6 address that is contained in the address block of any entry in either of the following IANA registries:"
2 Likes
No, there’s no blockchains involved. All systems are under the control of Let’s Encrypt so it’s not a solution that fits that problem.
We do operate a Certificate Transparency log, which has some properties in common with blockchains, and arguably is depending on how loose your definition is.
We have considered what it would mean for techniques like CT to be applied to domain validation as well, but that’s all just ideas at this point.
9 Likes
That's a good point about CT like techniques for DV. What do you think about blockchain for such a purpose where consensus is transparent and multi nodes participate? Can it be a viable solution?
This may help:
Experiences Deploying Multi-Vantage-Point Domain Validation at Let’s Encrypt
A solution to which problem?
One does not provide solutions to non-existing problems usually.
No, it does not. I'm familiar with multi-vantage-point validation, but that paper does not provide any reason to include the hyped "blockchain" and to which problem that would be a solution.
6 Likes
I don't really understand how "Blockchain" would improve, or even conduct domain validation.
The goal of domain validation is to make sure that the person requesting the certificate also controls the domain. I can't think of many better ways to do it (that wouldn't turn it into a rube goldberg machine) than asking the requestor to perform an operation that only someone with control of the domain can complete (in this case, serving a special file or adding a dns entry)
I guess you could log validations in some sort of Merkel tree but I don't think that's what is being suggested here.
2 Likes
Public blockchain technology can be highly beneficial for validating domains from multiple perspectives. By utilizing geo-separated, randomized validator nodes and utilizing a consensus-based approach, the process of domain validation can be greatly enhanced. Furthermore, the use of a public blockchain adds transparency and auditability to the process naturally. @mcpherrinm can you please comment on this. This seems a very interesting use case.
That's currently already happening and doesn't require a blockchain.
Is that necessary? What does it add to CT logs? Why would you want to have a transparant and auditable validation process?
4 Likes
Let's Encrypt already uses multi perspective validation. The validators must agree before the certificate is issued (The validators are all operated by Let's Encrypt, which also owns the private key). Issued certificates are also permanently logged so mis-issuances can be detected.
Are you suggesting that validation be outsourced to the general public?
2 Likes
If we did something, it would likely be in the “transparency” side of things: a log of validations in some sort of Merkle tree ledger.
Potentially we’d even consider something like partnering with other CAs to share validation infrastructure too, but I imagine we wouldn’t be doing anything like a public consensus system.
None of this is happening anytime soon: it’s just engineers having ideas and talking to each other, not anywhere close to even making plans.
5 Likes
In what way does the process currently lack transparency or auditability?
5 Likes
Blockchain systems are vulnerable to 51% attacks.
Why would anyone place certificate issuance at such risk within a "public" system?
If they were private (audited) blockchain systems [maintained separately by each CA]...
This might stand a better chance.
But then it would have to be made readable to the public.
This is something that isn't even on the drawing board (yet).
Simply put:
Doing this wouldn't solve anything that hasn't already been solved.
It may make things more public but at a very steep price in security and design.
I do like the idea of having an alternate path [outside the normal Internet] to conduct CA business...
But this leaves much to be desired.
4 Likes
How? Literally, how?
Nothing in your comments are substantive or topical as they might relate to Domain Validation in any way. There is nothing to extract from those comments aside from meaningless technobabble about blockchain, with the words "domain validation" thrown in.
There is no proposal as to what information might be placed into a blockchain, how that information would get there, how that information would be validated, kept current or refuted, or how anything regarding "blockchain" could possibly fit together with Domain Validation.
The comments honestly suggest a complete lack of understanding in Domain Validation.
Domain Validation is the process of ensuring a Certificate request has originated from the entity who legitimately controls the domain. This is currently accomplished by a timely, ephemeral, assertion of control over either i) a privileged port on the domain's infrastructure [e.g. HTTP-01, TLS-ALPN-01 challenges] or ii) the primary DNS records [e.g. DNS-01 challenge].
Exactly how could control of a domain be asserted via blockchain, as that technology is completely independent of the global DNS system and networking in general? The only way I could imagine this ever being possible, is if ICANN standardized and required all domain registration activity to occur on a centralized blockchain of it's choosing. Short of that happening, one would likely have to utilize the existing methods of Domain Validation to assert the legitimacy needed to authoritatively publish this sort of information onto a blockchain – so you'd likely be developing an entirely new set of RFCs/standards that require authentication with the existing Domain Validation methods, in order to support a new blockchain enabled validation system for questionable and suspect benefits. That would require an enormous amount of effort to implement, and the only tangible benefit is transparent logging of the validation method - which the CAs are already interested in handling and we will likely see required by a future iteration of the Baseline Rules or browser requirements.
As others noted, no existing problem has been articulated. In regards to the paper linked to above, the explicit conclusion is that MultiVA architecture is beneficial for a wide variety of reasons and should be adopted industry-wide as a standard.
11 Likes
This.
7 Likes
I second that.
7 Likes
This is a slight tangent but I have yet to find any use for Blockchain besides a means of payment or speculative investment. That couldn't be done better by traditional well understood methods at least.
Every single one I've found is just a bunch of buzzwords thrown together.
This is a good example of this. It's a confident statement that Blockchain will improve a process, while neglecting to do a proper comparison of the existing system, traditional methods, and how Blockchain will actually work.
6 Likes
The late @pde, a founder of Let's Encrypt, was interested in systems similar to Namecoin and whether Let's Encrypt could do something to help them.
What we saw when setting up Let's Encrypt was that the existing web PKI (1) had a ton of highly specific rules and (2) was very optimized for the case of letting people type names into browser navigation bars and get "what they expect" (which admittedly is extremely ill-defined and currently reflects various kinds of political compromise).
That system doesn't have a lot of flexibility to merge in other trust and naming models in parallel with the existing one, nor would the industry be happy if a certificate authority decided to unilaterally start issuing certificates validated in a fundamentally different way or with a fundamentally different meaning. However, Peter pointed out that publicly-trusted certificates could contain extensions that are pointers into other naming systems, as long as the certificate authority has validated the link and can attest to the information contained in the extension. So, if someone used something like Namecoin or, say, operated an onion site in Tor, it would be possible to have an X.509 extension which said "you can also reach this entity in a different way at ...", and that could conceivably be included in Let's Encrypt certificates. (I believe that onion sites currently use an HTTP header for this same purpose, but you could imagine that it could also be added to the certificate data for stronger security and transparency.)
I think some of that stuff would still be interesting, and, at least from Peter's point of view as I recall it, the ability to facilitate experimentation within naming systems even in that limited way is a nice advantage of running a CA.
However, the original suggestion of using a blockchain for distributed validation doesn't fit well with the web PKI as we actually know and love (?) it. In this system, a single identified entity is responsible for saying whether, to its knowledge, the ownership of a particular name has been properly confirmed, using specific methods that are explicitly specified by the industry.
I think @mdanish might be saying that we could get more perspectives in a DV validation process by inviting outside entities to declare whether they saw the same thing that the CA did. While this is not undesirable, it (1) would make the certificate issuance process much slower, (2) would not specifically satisfy the CA's obligations under industry rules, (3) would potentially be vulnerable to a Sybil attack in which an attacker created a lot of fake notaries which claimed to agree with the attacker's desired view of the network, and (4) could probably be done faster and more cheaply in a slightly less decentralized way involving transparency logs. [Edit: (5) It might allow third parties to selectively perform a denial of service attack against a CA, including by falsely claiming to be unable to validate specific sites that the third party dislikes.]
More fundamentally, the potential benefits are different depending on whether you do or don't trust the CA itself. It's clearly very legitimate not to want to have to trust CAs, and the Certificate Transparency system might be said to only go 90% of the way to fixing the problem rather than 100% of the way. But if you don't trust the CA, you should probably be aiming for an entirely different underlying naming and trust model (perhaps along the lines of Namecoin); if you do trust the CA but are concerned that the CA could be tricked by attacks that manipulate network infrastructure, you can still mitigate those more cheaply by having the CA itself create simple non-blockchain-based trust relationships with a greater diversity of validators (either by renting more infrastructure or by signing contracts with volunteers or something). The risk that the validators in particular will retroactively lie about what they told the CA during a validation process isn't a very important one in any threat model I'm aware of!
8 Likes