Hacker News Reader

Comment by tialaramex | Hacker News Reader

This is why Let's Encrypt is zero cost by the way. I'm certain Hanno knows that, but for everybody else:

The purpose of ISRG (the not-for-profit which runs Let's Encrypt) is to drive automated issuance for Web PKI certificates. Nothing about this directly means they should be free - surely a not-for-profit could deliver this as an at-cost service, so why zero cost when that's not a core goal?

Machines don't have wallets. If they charge even 1¢ for a Let's Encrypt certificate (which would certainly cover costs at current issuance rates) now there needs to be a payment flow, which the machine needs help with because it doesn't have money. At zero cost all of that goes away and leaves you only solving engineering problems to achieve your goal of automated issuance.

View on HN

I wish there were a way of sending $0.01, by sending $10 with probability 0.001. That is, you and I negotiate a random seed (using something like Diffie-Hellman) and then we can generate probabilistic microtransactions and only transfer the $10 in the p=0.001 case.

EDIT: fixed arithmetic, thanks skj

This is smart! Why not build it?

I suspect the probabilistic aspect would not actually be popular.

Yes, I think people would hate it for the same reason they love gambling slot machines. People overweight rare and random events. You'd always remember the one time you got dinged $10 for looking at some lame clickbait article.

You wouldn’t need to sell it as random to the end user.

That's a good point.

I've always wondered whether probabilistic micropayments would fly under sharia-compliant finance.

You'd have to have some way to enforce that people actually make the payments. And once you do that, it seems like an intermediary that just aggregates microtransactions and takes care of settlement at the end of the month or whatever would be a lot easier.

0.001

This sounds great for the recipient, who will get approximately the amount of money they'd otherwise get, but bad for the sender, who now has to budget a thousand times more than they were intending to spend.

Or more precisely, it's good for the party operating at scale and bad for the individual participant. This is the opposite of how most financial schemes handle unpredictable events: they put the risk on the party that can absorb the risk by letting it be lost in the noise, and take it away from the party that cares deeply about small amounts. Insurance companies will charge everyone the same amount, whether it's a customer that will ultimately bring them a bit of revenue or ultimately cost them a lot of money: the price for the individual customer is fixed. A plane flight costs the same amount of money whether there are strong tailwinds and the plane flew cheaper than expected or whether there was bad enough weather that the flight had to land somewhere for refueling, and the cost of the occasional rare disruption is built into the ticket.

This trick is mathematically nice, but there isn't really a reason for a consumer to prefer it to even paying $.02, unless the consumer is also paying at scale (in which case you can just aggregate the transfer and not use this scheme at all).

Great points, but can't you tweak the idea somehow by also buffering individual participants? I could imagine a service here could be worth a lot more than ~$10 user.

This is only needed for micropayments so a buffer of like $5-10 could be fine if you could somehow otherwise otherwise verify the user / monetize the relationship. Best way I can think of that preserves privacy is to serve image only ads through the payment network in an appropriately boxed window every time you add a tip to the randomized micropayment scheme.

One down vote. The idea's not a winner among the HN crowd. Oh well.

Maybe, someday, micropayments will be good.

This model works maybe for uses where small value transactions aren't worth the cost or hassle, but that's not the (main) problem here. It's that payment itself adds a layer of complexity.

And if the problem is that even simple payment complicates things, complicated (probabilistic maybe or maybe not) payment isn't going to make it better.

Lightning does exactly this for sending amounts less than 1 satoshi (minimum unit of the Bitcoin protocol)

I like how you said "WEB PKI". This works for the web, but the problem of verifying domain ownership for non-web interner remains. If ever there is a new version of DNS it should assume registrars will provide this CA service for free (or for whatever the domain costs)

Web PKI is just its name‡, like my name is tialaramex, names are not meanings. The Web PKI is a PKI for TLS services with names from the public Internet not just for HTTPS (the web).

Names meaning mostly DNS names like news.ycombinator.com but also numeric names such as 1.1.1.1

The Baseline Requirements (the rules Certificate Authorities agreed to obey some years back now) currently provide 13 potential ways to verify domain ownership, but these ways are sometimes called the Ten Blessed Methods dating back to when Gervase Markham was alive and worked on the Web PKI.

Although some of the Ten Blessed Methods are specific to the web in practice, such as 3.2.2.4.6 which involves creating a document to be retrieved from a web site, others really aren't such as 3.2.2.4.7 which is just a DNS change. Let's Encrypt offers both these (as challenges http-01 and dns-01 respectively)

Method 3.2.2.4.12 is specifically for domain registrars in the sort of relationship you're talking about, and is used by some registrars which also have a CA business (such as Google) today I believe.

‡ It got this name because the Web is why this PKI exists. SSL was invented by the Netscape Corporation, whose Web browser is the ancestor of today's Firefox. Netscape's successor, the Mozilla Foundation and Mozilla Corporation continues to be the most visible and only public oversight for the Web PKI. Perhaps if instead some other group had secured the Network it would be named, say, the Usenet PKI, or the IRC PKI or the NetBSD PKI, but they didn't and it isn't.

Names are not meanings but they describe a meaning. Webpki is framework used to verify public key ownership,specitically for TLS like you mentioned.

What makes webpki unique (and correct me if I am wrong) is how responsibilities are separated such that domain ownership is established by a 3rd party (like ISRG) as opposed to by the domain registrar. Logically speaking, the party transfering or registering domain ownership (for a fee) would also issue you a certificate at the time of transfer/registration. The different approaches to verify ownership would not be needed if the more sane approach was taken to begin with.

As you know, DNS is a protocol sepatate from TLS or other protocols. As such, domain ownership/control validation should be contained within the domain name system (also, why dnssec,dane and other efforts are under way, but they don't address the root cause of the problem).

For method 3.2.2.4.12 (and thanks for informing me about this), my comment was that it should be mandatory (not optional) for registrars to issue DV certs.

While I appreciate the ISRG, there are cases where using letsencrypt is not practical ,that aside, one org controlling so much of the web goes against the very concept of having TLDs that are independent in purpose/function. It would be more architecturally sane if what the ISRG does now was instead done at least at the TLR level. (E.g.: .com's owners should issue certs that says site.com belongs to whoever has this cert)

For the impractical corner cases: let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain. Or let's say I need non-TLS x509 such as ipsec.

Let me start at the end:

> let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain.

You should use Let's Encrypt's implementation of 3.2.2.4.7 which is the dns-01 challenge as I already mentioned. Or use another vendor's own implementation of 3.2.2.4.7 or any of the half a dozen or so non-web methods listed.

> Or let's say I need non-TLS x509 such as ipsec.

The Web PKI can't help you. Leaf certificates in the Web PKI contain an EKU 1.3.6.1.5.5.7.3.1 which says their purpose is TLS server authentication. There is no global public PKI for IPsec. Feel free to try to make your own, but I expect it will be an expensive and thankless task.

The central issue of a PKI is trust and domain name registrars are not on the whole very trustworthy. We're talking about the industry which invented Domain Front Running - the idea of waiting until a customer shows interest in a unique product (a domain name) and then buying it yourself so that they'll have to buy it from you at an inflated price.

I sympathise with the desire to build a parallel PKI baked into the DNS system, but the Web PKI is not that system and there's no practical way to mutate it into that system. If you believe DANE is the only way forward you should go help people make DANE work better, not argue against the Web PKI.

Issuing "a certificate" at time of domain registration greatly misses the point of Internet hierarchical naming by the way. While it would be technically possible for every domain to hold a single wildcard certificate and use flat naming (so news.america.ycombinator.com couldn't exist, it would need to be news-america.ycombinator.com) that's a terrible security choice. Necessarily where a service corresponds to one specific name the certificate and corresponding private key should be for that name only, and not a hierarchy of related names in order to mitigate risk.

I think you misunderstood, I was not arguing against WEBPKI, I was advocating for a better ideal solution that does not exist. WEBPKI solves real problems well. I don't care for DANE either.

To address your concern, clients will have TLD certs in their trust store. TLDs issue intermediate CA certs to registrars. When you get a domain, they issue a cert (not x509 neccesarily) that allows you to issue certificates like an intermediate but restricted to that domain and its subdomains. So news.america and news. Under ycombinator.com will have separate certs,signed by the owner of ycombiator.com which on turn has to have their CA cert signed by a registrar.

This actually can improve security, because you can isolate your intermediate signig key from the rest of your services, and possibly have a dynamic process of issuing extremely short lived certs by your CA box to all of your services. Code signing certs,s/mime,client certs, eap-tls,etc... Can all be more easy to use. For example, if I could use eap-tls to connect to wifi at an airport or starbucks using a cert I issued myself under my domain (or under my work/school domain). Things that have been notoriously hard to adopt like TLS client certs could easier to use because anyone can have a client cert issued to them by any domain owner (likely the domain of their email provider for most) because any site can verify their client cert using this system and anyone with a domain can issue certs. This is the natural and most sensible way.

As for trust, you already trust them with the power to transfer your domain. If someone compromises your registrar account, what stops them from taking over the domain,pointing it at their own servers and getting a new cert from ISRG? Imagine getting a government ID and to verify it's legitimacy,people have to contact 3rd party companies instead of the government, that makes no sense. Things are the way they are because public key crypto was not used widely when DNS and the internet became a thing.

> which the machine needs help with because it doesn't have money

How long does it take to mine 1¢ worth of bitcoin? Or, is there anything else a machine can do in a relatively short timeframe that’s worth 1¢ to someone else?

t2.micro instances on AWS rent for about 1¢/h...

Like what? If you have anything my computer can do to generate 1c/10seconds with no input from me, that’s $3.60/hour income running twenty four seven; I’ll buy a few and retire right now.

Computers have costs associated with running them. electricity, infrastructure for them to run. The cost is not zero.

Even at the height of the crypto boom my computer with a very fast graphics card at the time made like ten bucks a day.

Is it still generating money for you? Still $10 / day?

Nope, not making enough to be worth the power drain and the noise anymore.

LE certificates last 90 days. $3.60/hour is enough to cover renewal for almost a million certificates. The mining doesn't have to be done during the renewal process. You can do the mining gradually between renewals.

This kind of thing has been proposed but you can easily end up in a situation where the device uses 2c of electricity to mine 1c and then you'd be better off preloading the device with, say, ten years worth of currency instead of mining.

On a CPU it’s gonna be dollars or electricity.

The whole point of profitable mining is to build asics such that the cost of electricity gets lower than the mining rewards.

21 was pitching IoT ASIC mining and it still looked like a waste of electricity.

I'm not a bitcoin person, but...

I don't think you can mine $0.01 worth of bitcoin. Most of the time, you'll lose the race to find the correct hash collision and so you'll end up with nothing. Other times, you'll win and get the reward for the block which is 12.5 BTC at the moment (IIRC). People do join collectives to pool their mining power, but there isn't predictability to when the collective will end up with a coin. If you're looking to set up a web server, you don't want to be waiting days or weeks or whatever while your collective tries to win a block. Theoretically, you could buy a lot of computing power and always get unlucky.

So you can't really get a penny of bitcoin via mining.

you can join a mining pool.

But mining once cent worth of bitcoin would cost you multiple dollars on a CPU.

Realistically, larger pools mine multiple blocks per day and can pay out daily. 21 even came up with a scheme to front BTC to the device and make it up later, but that's excessively complex IMO.

Reply on news.ycombinator.com