💾 Archived View for rawtext.club › ~sloum › geminilist › 000478.gmi captured on 2020-11-07 at 01:31:13. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Tue Mar 3 19:16:20 GMT 2020
- - - - - - - - - - - - - - - - - - - ``` 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 toostrongly 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 intoimplementing a proof of concept. But the truth is that I think it's toolate in the game for this kind of change. Replacing TLS with *anything* else would completely break every existingpiece of Gemini software, which is a non-trivial amount, written by manydifferent people of varying degrees of continuing activity in theproject. There is a very real chance that this kind of change wouldintroduce a permanent schism between "New Gemini" and "Old Gemini" whena subset of servers (in both senses of the word) and clients were notupdated. Not only would software break, but I imagine a lot ofparticipants in the projet would be unhappy as well. I worry that thecommunity is too small and fraile to survive what would effectively be afork. It's possible some kind of compatibility-maintaining change could benegotiated with the use of protocol verison numbers, but I have always,and still have been, opposed to the idea of versioning Gemini, because Isee this as basically negating all the effort that was put into avoidingextensibility. My intent has always been to get it right (or closeenough) the first time, in a relatively short period, and then leave itfixed - more or less as per Gopher. I realise that's a tall order. Theidea was that Gemini would be so simple that this would be possible.Unforseen problems requiring later changes are a symptom ofovercomplication, which interferes with anticipating problems. I understand that there's a lot *not* to like about TLS. And while Iabsolutely understand the importance of the "don't roll your own crypto"dogma, I do also understand that it *is* a dogma, which has a stagnatingeffect, especially when overextended - there is a real differencebetween combining established and well-tested primitives into a newprotocol and a totally naive person who doesn't know block ciphers fromstream ciphers coming up with something truly from scratch and assumingit'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 Geminiagain and we could be a bit more agile in core aspects of theprotocol's design, I'm not convinced I wouldn't still choose TLS. Themost important argument in its favour, IMHO, is the simple fact thatTLS is going to be used, studied, and improved/maintained by some ofthe best security people in the world for a long time to come, forreasons *entirely* unrelated to Gemini. By going with TLS, webasically get to piggy-back on all of this, for free. The moment wechange to anything else, there is immediately a 90% reduction in theamount of attention being paid by anybody to our security system.That's very hard to argue against, I would say, even in the interests ofsimplicity. And, for what it's worth, TLS *is* getting simpler. TLS1.3 drastically reduced the amount of different configurations which arepossible. I really wanted to spec TLS 1.3 as the minimum supported forGemini, but it's not yet supported in LibreSSL - which is itself allabout simplifying TLS, so discouraging adoption of it would be counterproductive 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 ofexplicitly 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. >