On Tue, Mar 03, 2020 at 02:20:57PM +0200, Ciprian Dorin Craciun wrote: > (Although I think the change of adopting anything besides TLS is > closer to 0 at this moment, which I would say is a shame...) You are pretty well right about this (and I won't even argue too strongly the fact that it's kind of a shame). I really hate to do anything like shutting this line of discussion down, especially after you have already invested so much effort into implementing a proof of concept. But the truth is that I think it's too late in the game for this kind of change. Replacing TLS with *anything* else would completely break every existing piece of Gemini software, which is a non-trivial amount, written by many different people of varying degrees of continuing activity in the project. There is a very real chance that this kind of change would introduce a permanent schism between "New Gemini" and "Old Gemini" when a subset of servers (in both senses of the word) and clients were not updated. Not only would software break, but I imagine a lot of participants in the projet would be unhappy as well. I worry that the community is too small and fraile to survive what would effectively be a fork. It's possible some kind of compatibility-maintaining change could be negotiated with the use of protocol verison numbers, but I have always, and still have been, opposed to the idea of versioning Gemini, because I see this as basically negating all the effort that was put into avoiding extensibility. My intent has always been to get it right (or close enough) the first time, in a relatively short period, and then leave it fixed - more or less as per Gopher. I realise that's a tall order. The idea was that Gemini would be so simple that this would be possible. Unforseen problems requiring later changes are a symptom of overcomplication, which interferes with anticipating problems. I understand that there's a lot *not* to like about TLS. And while I absolutely understand the importance of the "don't roll your own crypto" dogma, I do also understand that it *is* a dogma, which has a stagnating effect, especially when overextended - there is a real difference between combining established and well-tested primitives into a new protocol and a totally naive person who doesn't know block ciphers from stream ciphers coming up with something truly from scratch and assuming it's good because none of the three friends they asked could break it. But all that said, even if this were the very early days of Gemini again and we could be a bit more agile in core aspects of the protocol's design, I'm not convinced I wouldn't still choose TLS. The most important argument in its favour, IMHO, is the simple fact that TLS is going to be used, studied, and improved/maintained by some of the best security people in the world for a long time to come, for reasons *entirely* unrelated to Gemini. By going with TLS, we basically get to piggy-back on all of this, for free. The moment we change to anything else, there is immediately a 90% reduction in the amount of attention being paid by anybody to our security system. That's very hard to argue against, I would say, even in the interests of simplicity. And, for what it's worth, TLS *is* getting simpler. TLS 1.3 drastically reduced the amount of different configurations which are possible. I really wanted to spec TLS 1.3 as the minimum supported for Gemini, but it's not yet supported in LibreSSL - which is itself all about simplifying TLS, so discouraging adoption of it would be counter productive on that front. This is why we have TLS 1.2 as the minimum. If it softens the blow any, I'm absolutely open to the idea of explicitly disallowing some TLS 1.2 configurations. Cheers, Solderpunk > #### About "pro-TLS", and "don't roll your own" > > [I.e. This part is a counter argument to my previous emails. I still > think we can do "simpler", but I do like to be fair, and thus I'm > debating myself...] :) > > > Bellow I'll point out three articles, written by three different > people (which after searching the internet seem to be knowledgeable in > this domain, perhaps not Schneier / Bernstein level, but still much > better than the average developer), in a time span of about 10 years. > (The section we are interested in is `client-server application > security`, and not `website security` because the later actually means > "HTTPS security", thus TLS is mandatory, although the former > completely ignores certificates, as in X.509, thus only SSH-like > assumptions.) > > * [2018] https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html > * [2015] https://gist.github.com/tqbf/be58d2d39690c3b366ad > * [2009] http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html > > > >From [2009] (although I would say it's an incomplete advice as it > doesn't say what to do next): > ~~~~ > One of the reasons OpenSSL has such a poor track record is that the > SSL protocol itself is highly complex. Certificate chains, revocation > lists, ASN.1, multiple different hashing and encryption schemes... > when you have over a hundred thousand lines of code, it's no wonder > that bugs creep in. > ~~~~ > > > >From [2015] (Colin is the author of the [2009] article): > ~~~~ > What happens when you design your own custom RSA protocol is that 1-18 > months afterward, hopefully sooner but often later, you discover that > you made a mistake and your protocol had virtually no security. That > happened to Colin, but a better example is Salt Stack. Salt managed to > deploy e=1 RSA. > > [...] > > Most of these attacks can be mitigated by hardcoding TLS 1.2+, ECDHE > and AES-GCM. That sounds tricky, and it is, but it's less tricky than > designing your own transport protocol with ECDHE and AES-GCM! > > In a custom transport scenario, you don't need to depend on CAs: you > can self-sign a certificate and ship it with your code, just like > Colin suggests you do with RSA keys. > > Avoid: designing your own encrypted transport, which is a genuinely > hard engineering problem; using TLS but in a default configuration, > like, with "curl"; using "curl", IPSEC. > ~~~~ > > > >From [2018]: > ~~~~ > In custom protocols, you don?t have to (and shouldn?t) depend on 3rd > party CAs. You don?t even have to use CAs at all (though it?s not hard > to set up your own); you can just use a whitelist of self-signed > certificates ? which is approximately what SSH does by default, and > what you?d come up with on your own. > > Since you?re doing a custom protocol, you can use the best possible > TLS cipher suites: TLS 1.2+, Curve25519, and ChaPoly. That eliminates > most attacks on TLS. The reason everyone doesn?t do this is that they > need backwards-compatibility, but in custom protocols you don?t need > that. > > [...] > > Avoid: designing your own encrypted transport, which is a genuinely > hard engineering problem; using TLS but in a default configuration, > like, with ?curl?; using ?curl?, IPSEC. > ~~~~ > > > The takeaway: if we go with TLS, let's mandate: > * TLS 1.2 with TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 > https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 > * or, TLS 1.3 with TLS_CHACHA20_POLY1305_SHA256 > https://ciphersuite.info/cs/TLS_CHACHA20_POLY1305_SHA256 > * as for certificates only ECDSA, which seem to be available also via > Lets Encrypt; > > These options are also suggested by both Mozilla and CloudFlare: > * https://wiki.mozilla.org/Security/Server_Side_TLS > * https://developers.cloudflare.com/ssl/ssl-tls/cipher-suites > > > > > #### About the noise protocol > > I've glossed over the Noise protocol specification, however before > getting into that I've read the first link bellow: > > * https://latacora.micro.blog/factoring-the-noise/ > * https://noiseprotocol.org/noise.html (this is the actual specification); > > Basically I think the only Noise protocol instance that pertains to > `gemini://` is the `XX` exchange pattern, citing from the first link > above: > ~~~~ > XX and XK require an extra round trip before they send over the > initiator?s static key. Flip side: they have the strongest possible > privacy protection for the initiator, whose identity is only sent to > the responder after they?ve been authenticated and forward secrecy has > been established. > ~~~~ > > In fact Alexey Ermishkin together with Trevor Perrin (the original > author of the protocol) have started a project called NoiseSocket, > which basically just focuses on the the `XX` pattern. (As for > credentials, Trevor Perrin worked for WhatsApp in designing the Noise > protocol, which is still used today.) > > * https://github.com/noisesocket/spec > * https://noisesocket.org/post/1/ -- I strongly suggest reading this > document if one is interested in the Noise protocol; > > The only disadvantage with Noise (or NoiseSocket) is that given the > frame size is limited to 64K, in case of `gemini://` we need to > implement extra "chunking" for it to work for bodies. (Alternatively > we can just use it as we do TLS, namely a "stupid pipe that just > applies encryption"...) > > > > > #### The part about other alternatives > > I've found the following project that also does a "state-of-the-art" > analysis (though granted in 2015): > > * https://github.com/auditdrivencrypto/secure-channel > * https://github.com/auditdrivencrypto/secure-channel/blob/master/prior-art.md > * https://github.com/auditdrivencrypto/secure-channel/blob/master/properties.md > * https://github.com/auditdrivencrypto/secure-channel/blob/master/draft.md > * https://github.com/auditdrivencrypto/secure-channel/blob/master/draft2.md > > (I don't know his credentials, thus I would assume nothing.) > > The "state-of-the-art" is quite "high-level", but it provides a nice > starting point. The properties document is a good check-list to > analyze any proposal against. (The only issue, is that he is > interested in building a peer-to-peer network, thus at least the > public key of the server is known in advance.) > > The second draft (i.e. `draft2.md` above) is quite interesting, > although as said it does one require to know beforehand the server's > public key. > > > > > #### About my previous proposal > > I'll have to think harder about it (within my limited cryptographic > expertise), and perhaps submit it to a cryptographers community for > feedback. > > At the moment I can see only a minor privacy flaw in it: the client > discloses its identity (and proof of identity) to any server; instead > it should first wait for the server to disclose its identity (and > proof of identity) before proceeding. > > This issue stems from the fact that the `transport_prepare` function > is "symmetrical" and tries to reduce network round-trips; instead the > client could first wait for the server verifier and then send its own > (i.e. just a minor change to that function). > > Ciprian. >
---
Previous in thread (12 of 18): 🗣️ Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)
Next in thread (14 of 18): 🗣️ Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)