The login problem was attempted to be solved by Mozilla's "persona", now deprecated. I like the general idea that I strongly authenticate to my browser, which can then "vouch" for me to various sites using cryptographic tokens that are otherwise useless (so no cracking/stealing passwords, etc). The devil of course would be in the details.

The devil is that the corporations able to influence this change directly benefit from current identity systems. Google for example has huge infrastructure in place linking its products together and includes tracking and other features that would only work with the current system.

Sorry that didn't work out :(

>The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH.

You do realize that's trust-on-first-connect aka self signed certigicates, right? Especially with LE, thats worse in every way to the CA model.

>Logins on websites with a public / private keypair ala SSH.

Pretty much client certificates minus PKI.

SSH is only trust-on-first-connect if you choose to behave that way. Whenever you connect to a new machine, it prompts you "I don't recognize this machine, and its fingerprint is XXXX. Do you trust that?"

I don't see how the option to trust websites is worse than having a bunch of certificate authorities choose who I'll trust for me.

How would you possibly know which fingerprints to trust? Also, do you honestly think there is any hope for the average user to understand what that means and know what to trust and what not to trust? IMO, that is a massive step backwards in usability, which directly impacts the overall security of a given solution. If something is not usable, then people will figure out a way around it and security then goes out the window.

For example, if users were responsible for knowing which fingerprints to trust for a given website, they would most likely just click "ok, trust it" for everything. Then, you're overall security goes way down because now people are conditioned to click "accept" to everything, regardless of the impact.

Signed archives of trusted or untrusted fingerprints, distributed by various and independent authorities is one option.

Trust is, by definition, an extention of solidity or support. CA is a trust model, which has proved both brittle and unworkable.

http://www.etymonline.com/index.php?term=trust&allowed_in_fr...

Google and other services presently provide extended trust and validity assessments for websites: pinned certificates, malware scans, and the like. A limited number of such reliable schemes would scale reasonably well, and should prove useful.

I'm not saying "perfect", I'm saying "useful".

DANE perhaps?

http://www.internetsociety.org/deploy360/resources/dane/

Interesting, that's a possibility.

I was thinking of something more akin to, say Google's pinned certificates (something which practices such as Let's Encrypt actually makes harder AFAICT):

https://security.stackexchange.com/questions/29988/what-is-c...

Or something that might be a parallel of email reputation services -- SenderBase / IronPort (now Cisco) rating email servers by their spam loads, etc.

Rather than negative reputation, a positive reputation (vouch rather than warn) might be viable. (Negative ratings systems, digital or otherwise, tend to inspire various legal assaults.)

As an individual user, you have no better information than your knowledge of the website and its claims on security, maybe its brand, and what your social circles claim about its security practices. A certificate authority at least has the potential to aggregate data and from there assess the security of a website. The original ideas behind certificate authorities are not dissimilar from insurance.

SSH-style login is still something I'd really fucking love. Much more secure way of logging in, easy protocol for storing multiple passwords, and easy authorization/deauthirzation of passwords/keys.

Client TLS certs already exist, and they are a massive pain for the average user.

I remember StartCom used client TLS certs, the only place where I ever saw them in use, and the browser workflow was certainly clunky. I'd hate to see a non-techie have to deal with it.

They worked quite smoothly for me. I actually liked StartCom's login process.

So I have heard of client TLS authentication, but does it exist for the web (I mean just in principle, not whether it is really used). That is, do browsers support it?

The thing is, if it is a massive pain for average users, then that is an own-goal. Look at SSH: there is no certification chain there. All you do is generate a keypair and then (here's the awkward bit) magic the pubkey over to the server.

It would be easy enough for a website to make pubkey installation a seamless part of the sign-on workflow.

It is a massive pain for average users but it's well supported by browsers is because big corporations have IT departments that provision (and admin) computers for their users, average or otherwise, and the provisioning process includes setting up client certs.

So while browsers do support client certs, there has been very little effort to make them easy to install due to a chicken-egg situation. They're hard to use, so no one uses them, but no one (random sites on the Internet, that is) uses them for client auth because they're hard to use.

Yes, browsers have supported client certificates for decades and continue to today.

Token binding provides something like that. With token binding you have a private/public key pair for each site that supports it. An identifier is created from the public key and signed with the private key, to prove your identity.

https://www.sjoerdlangkemper.nl/2017/07/05/prevent-session-h...

> Deprecation of email or rather its insecurity.

We would need something to replace it with, there is really nothing right now.

While I agree, there is definitely movement and recent movement [0][1] , I just wish I had the knowledge to contribute. I am great and figuring out how things work, breaking them and understanding them. Building from scratch is a bit above my head, albeit I have a few ideas....

[0] https://news.ycombinator.com/item?id=14708783 [1] https://magmadaemon.org/

We already have standards for encrypting/authenticating email transfer between mail servers and between the server and user agent.

This doesn't solve the problem of mail being encrypted in transit. As far as I can tell the server operator can still read the user's mail. What we need is end-to-end encryption, lack of support in MUAs (iphone mail app, thunderbird etc.) is the problem here, it has really nothing to do with the server.

> lack of support in MUAs (iphone mail app, thunderbird etc.)

Thunderbird supports S/MIME out of the box and PGP through an addon, so I'm not sure what other kinds of end-to-end encryption you'd want to see. Not sure about the iPhone mail app.

> The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH.

Would HPKP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...) cover that for you?

I love the encryption ideas.

Do you know if PGP public/private key pairs can be used for ephemeral keys? I'd hate to rely on the same secret to store everything throughout time.

I haven't had my morning coffee, but I believe that lack of forward-secrecy is exactly the main drawback with PGP as a protocol; but it's been a while since I looked at it

PGP allows creation of subkeys. I'm not entirely clear that that's useful here, but it might be.

My concept (high level) for dealing with things like server and user identities handled by key pairs:

Take keybase (or its conceptual basis) and distribute it. Each domain can host its own key server. You can post proofs on other domains to link domain identities or logins. So now my phone has a key that's attached to the identity jtsummers at legoflambda.org. You have a service. I register the identity jtsummers at legoflambda.org with your service. I can log in using the key from my phone. My laptop has its own key. My yubikey stores a third key for access while I'm traveling without my laptop. Each of those I've connected via some proof mechanism to my key server so I can log into your service using any one of those keys.

Google and others can also host a key server so my user at gmail.com identity can also be used or my facebook.com identity, again with multiple keys associated with them from my various devices. And possession of the private key can also be used to access the same services (perhaps paired with something like a TOTP or other shared secret if you want an extra layer of authentication).

Now you want to send a message to me, you can have a service similar to what keybase offers. You send a message to any one of my public identities or keys, it gets made available to all of them. You know me here on HN, you send it to that identity. You know me by some other forum handle or by my gmail account you use those. And since my public keys are all available, you can send an encrypted message that will be available to any one of my devices (which I can re-encrypt as I add and remove devices).

This also handles a lot of the problem with spam. Spammers now have to take the time to individually encrypt messages for every user. They have to publically post identities and keys so that users can authenticate them. And users can block spammers by blocking the keys associated with them and block an entire identity by blocking all the keys associated with the spamming key. You want to ensure that that email from your bank is legitimate? Your bank should have a publically visible key server that all communications from them make use of. Whether they send the message in the clear with only a signature or if they send an encrypted message to you (preferred for privacy and security anyways).

This also helps with applications like signal/whatsapp which are presently tied to a single client instance. Now, I can associate my whatsapp key with multiple other keys (each on different devices, presumably). So you want to send me a whatsapp message, it can now be sent to all my devices. My phone number can still be an identity used by those services, but it's no longer the only one.

This was a particularly annoying case for me as I travel internationally with a separate phone than my US phone since it's locked, I had to enable WhatsApp on my travel phone using my primary cell number for ease of friends communicating with me (I don't have to get my secondary number to all of them and remind them to switch back once I'm done). If I could have connected my secondary device to my primary one then all messages sent to my main number would have been received by both, and messages sent from either would all appear to the recipient as belonging to the same identity.

====

This is not a well structured presentation, sorry. It's more the random thoughts that have been hopping around in my head for the last couple months between other more pressing concerns.