Designing a simpler alternative to TLS

I've been working on a simpler alternative to TLS, mostly for fun and also as a learning excersize to have a better understanding of how TLS works. You can find it here: https://sr.ht/~adnano/miso/ Obviously this has not undergone any security audits, so don't use it for anything serious. Biggest differences from TLS: - No certificate authorities; use TOFU instead - No version negotiation - No session resumption - Encrypted server name indication - Much simpler Let me know what you think!

It would be cool if Gemini dumped TLS and went with something simpler, but on the other hand it would make Gemini software a lot harder to implement since there's lots of TLS libraries out there for developers to use, whereas if we make a new thing (GLS?) code needs to be written in many different languages to support it. On the other hand, if it's simple enough, implementing functions or a library in your language of choice might not be too far-fetched. Ben -- gemini://kwiecien.us/

It was thus said that the Great Adnan Maolood once stated: > I've been working on a simpler alternative to TLS, mostly for fun and also > as a learning excersize to have a better understanding of how TLS works. > > You can find it here: > https://sr.ht/~adnano/miso/ > > Obviously this has not undergone any security audits, so don't use it for > anything serious. > > Biggest differences from TLS: > > - No certificate authorities; use TOFU instead > - No version negotiation > - No session resumption > - Encrypted server name indication > - Much simpler > > Let me know what you think! First off, the specification does not give enough detail to actually implement the protocol. There's nothing about the wire format, and I had to check the implementation to see you are using BARE message Encoding [1], yet *another* encoding scheme like JSON, BSON, CBOR, MsgPack, CapnProto, Protobuf, etc. etc. [2] Second, TLS libraries come with the cryptographic primitives required, and yes, there is negotiation that happens, but that's because as cryptographic primitives are broken, new ones can be slotted in and used. Here, if (and it could happen) Ed25519 is "broken" then what? At least with several supported primitives, the protocol can still be used while the broken primitive is removed. Even so, anyone attempting to implement Ed25519 is a fool for the pitfalls are subtle and *will* be exploited; I'm guessing you are assuming the use of libsodium (or God help you, libnacl) with this protocol, right? I'm no crytographic expert, but I don't see how this protocol prevents MITM attacks; the details in the key share (section 2.2.1) don't go into enough detail for my liking. How do I know I'm talking to the server in question, and not being invisibly proxied by Eve or Mal? And how does each side determine an insecure key share? What exactly goes over the wire? Also, some pseudocode would be nice as not everybody knows Go. -spc [1] https://baremessages.org/ [2] Groan.

On Sat, 21 Nov 2020 03:30:22 -0500 Sean Conner <sean at conman.org> wrote: > I'm no crytographic expert, but I don't see how this protocol prevents > MITM attacks; the details in the key share (section 2.2.1) don't go into > enough detail for my liking. How do I know I'm talking to the server in > question, and not being invisibly proxied by Eve or Mal? And how does each > side determine an insecure key share? What exactly goes over the wire? It seems to prevent this only to the same extent that the Gemini TOFU (mis-)use of TLS does. First, ephemeral keys are generated and the public keys are exchanged. The rest of communication is encrypted using these keys. The server then sends the client an Authentication message which contains the certificate and a corresponding signature of the ephemeral public keys. The client verifies that the signature of the public keys is correct according to the public key of the certificate. You could then just pin that certificate on first use if you trust that there is not a man in the middle at that moment. From that point, you can verify that it's the same certificate in all future exchanges. This is a weakness, but in principle the same weakness exists in the use of self-signed non-preshared certificates in Gemini. I think it's an interesting exercise, however unlikely to replace the use of TLS in Gemini. For Gemini, I'd much rather see conventions for peer verification of certificates where servers can share lists of certificates they use for different hosts, and self-revocation lists that contained self-signed revocation messages whereby a certificate can revoke itself. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201121/d69f00dc/attachment.sig>

This is a problem solved many times over. You will need to do better than the Noise protocol, which is the most compelling alternative to TLS. http://noiseprotocol.org/ https://noiseexplorer.com/ https://verifpal.com/ - Formal proofs or GTFO E.

On 11/20/20 8:53 PM, Adnan Maolood wrote: > I've been working on a simpler alternative to TLS, mostly for fun and > also as a learning excersize to have a better understanding of how TLS > works. > > You can find it here: > https://sr.ht/~adnano/miso/ > > Obviously this has not undergone any security audits, so don't use it > for anything serious. > > Biggest differences from TLS: > > - No certificate authorities; use TOFU instead > - No version negotiation > - No session resumption > - Encrypted server name indication > - Much simpler > > Let me know what you think! # 2.1 Protocol Overview Application Data: C <- Status 0 <- S C <- App Data <- S C -> Status 0 -> S C -> App Data -> S ... C <- Status 1 <- S -- Connection closed ## 2.4 Close Notify The client and server MUST send the status code FINISHED before closing the connection. 2.1 shows only the server sending a 'finished' status, but 2.4 says both sides must do so?

On Sat Nov 21, 2020 at 5:55 AM EST, Emery wrote: > This is a problem solved many times over. You will need to do better > than > the Noise protocol, which is the most compelling alternative to TLS. > > http://noiseprotocol.org/ > https://noiseexplorer.com/ > > https://verifpal.com/ - Formal proofs or GTFO > Thanks for the resources! Noise looks interesting indeed.

On Sat Nov 21, 2020 at 3:30 AM EST, Sean Conner wrote: > First off, the specification does not give enough detail to actually > implement the protocol. There's nothing about the wire format, and I had > to > check the implementation to see you are using BARE message Encoding [1], > yet > *another* encoding scheme like JSON, BSON, CBOR, MsgPack, CapnProto, > Protobuf, etc. etc. [2] The specification is still a very rough draft. > Second, TLS libraries come with the cryptographic primitives required, > and > yes, there is negotiation that happens, but that's because as > cryptographic > primitives are broken, new ones can be slotted in and used. Here, if > (and > it could happen) Ed25519 is "broken" then what? At least with several > supported primitives, the protocol can still be used while the broken > primitive is removed. If Ed25519 is broken, then it would be considered insecure, and a new KeyShare message could be added in a backwards-compatible way. > Even so, anyone attempting to implement Ed25519 is a fool for the > pitfalls > are subtle and *will* be exploited; I'm guessing you are assuming the > use of > libsodium (or God help you, libnacl) with this protocol, right? Yes, I assume that you would not implement the cryptography yourself. > I'm no crytographic expert, but I don't see how this protocol prevents > MITM attacks; the details in the key share (section 2.2.1) don't go into > enough detail for my liking. How do I know I'm talking to the server in > question, and not being invisibly proxied by Eve or Mal? MITM protection is covered in section 2.2.4. Essentially, the server signs the key share messages with its certificate private key, and the client verifies this signature. > And how does each > side determine an insecure key share? What exactly goes over the wire? A key share would be insecure if it is later "broken" as you said. I don't expect anyone to use this instead of TLS, it is mostly just for educational purposes and to gather ideas of what a simpler TLS could look like.

On Sat Nov 21, 2020 at 8:31 AM EST, Scot wrote: > # 2.1 Protocol Overview > Application Data: > C <- Status 0 <- S > C <- App Data <- S > C -> Status 0 -> S > C -> App Data -> S > ... > C <- Status 1 <- S > -- Connection closed > > 2.1 shows only the server sending a 'finished' status, but 2.4 says both > sides must do so? Only one side has to send the status code for the connection to be closed. I'll clarify that in the specification.

404. Did you bury your project? P. Am Freitag, dem 20.11.2020 um 21:53 -0500 schrieb Adnan Maolood: > I've been working on a simpler alternative to TLS, mostly for fun and > also as a learning excersize to have a better understanding of how > TLS > works. > > You can find it here: > https://sr.ht/~adnano/miso/ > > Obviously this has not undergone any security audits, so don't use it > for anything serious. > > Biggest differences from TLS: > > - No certificate authorities; use TOFU instead > - No version negotiation > - No session resumption > - Encrypted server name indication > - Much simpler > > Let me know what you think!