💾 Archived View for rawtext.club › ~sloum › geminilist › 000477.gmi captured on 2020-11-07 at 01:31:10. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Regarding `gemini://` over NaCL (replacing TLS)

Ciprian Dorin Craciun ciprian.craciun at gmail.com
Tue Mar 3 12:20:57 GMT 2020
- - - - - - - - - - - - - - - - - - - ```

OK, I've been doing some "light reading" about this topic, and this iswhat I've found out so far.

(Although I think the change of adopting anything besides TLS iscloser to 0 at this moment, which I would say is a shame...)




#### About "pro-TLS", and "don't roll your own"

[I.e.  This part is a counter argument to my previous emails.  I stillthink we can do "simpler", but I do like to be fair, and thus I'mdebating myself...]  :)


Bellow I'll point out three articles, written by three differentpeople (which after searching the internet seem to be knowledgeable inthis domain, perhaps not Schneier / Bernstein level, but still muchbetter than the average developer), in a time span of about 10 years.(The section we are interested in is `client-server applicationsecurity`, and not `website security` because the later actually means"HTTPS security", thus TLS is mandatory, although the formercompletely ignores certificates, as in X.509, thus only SSH-likeassumptions.)


	[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 itdoesn't say what to do next):~~~~One of the reasons OpenSSL has such a poor track record is that theSSL protocol itself is highly complex. Certificate chains, revocationlists, ASN.1, multiple different hashing and encryption schemes...when you have over a hundred thousand lines of code, it's no wonderthat 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-18months afterward, hopefully sooner but often later, you discover thatyou made a mistake and your protocol had virtually no security. Thathappened to Colin, but a better example is Salt Stack. Salt managed todeploy e=1 RSA.

[...]

Most of these attacks can be mitigated by hardcoding TLS 1.2+, ECDHEand AES-GCM. That sounds tricky, and it is, but it's less tricky thandesigning your own transport protocol with ECDHE and AES-GCM!

In a custom transport scenario, you don't need to depend on CAs: youcan self-sign a certificate and ship it with your code, just likeColin suggests you do with RSA keys.

Avoid: designing your own encrypted transport, which is a genuinelyhard 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 3rdparty CAs. You don’t even have to use CAs at all (though it’s not hardto set up your own); you can just use a whitelist of self-signedcertificates — which is approximately what SSH does by default, andwhat you’d come up with on your own.

Since you’re doing a custom protocol, you can use the best possibleTLS cipher suites: TLS 1.2+, Curve25519, and ChaPoly. That eliminatesmost attacks on TLS. The reason everyone doesn’t do this is that theyneed backwards-compatibility, but in custom protocols you don’t needthat.

[...]

Avoid: designing your own encrypted transport, which is a genuinelyhard 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 viaLets 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 beforegetting 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 linkabove:~~~~XX and XK require an extra round trip before they send over theinitiator’s static key. Flip side: they have the strongest possibleprivacy protection for the initiator, whose identity is only sent tothe responder after they’ve been authenticated and forward secrecy hasbeen established.~~~~

In fact Alexey Ermishkin together with Trevor Perrin (the originalauthor of the protocol) have started a project called NoiseSocket,which basically just focuses on the the `XX` pattern.  (As forcredentials, Trevor Perrin worked for WhatsApp in designing the Noiseprotocol, which is still used today.)


	https://github.com/noisesocket/spec* https://noisesocket.org/post/1/ -- I strongly suggest reading thisdocument if one is interested in the Noise protocol;


The only disadvantage with Noise (or NoiseSocket) is that given theframe size is limited to 64K, in case of `gemini://` we need toimplement extra "chunking" for it to work for bodies.  (Alternativelywe can just use it as we do TLS, namely a "stupid pipe that justapplies 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 nicestarting point.  The properties document is a good check-list toanalyze any proposal against.  (The only issue, is that he isinterested in building a peer-to-peer network, thus at least thepublic 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'spublic key.




####  About my previous proposal

I'll have to think harder about it (within my limited cryptographicexpertise), and perhaps submit it to a cryptographers community forfeedback.

At the moment I can see only a minor privacy flaw in it:  the clientdiscloses its identity (and proof of identity) to any server;  insteadit should first wait for the server to disclose its identity (andproof of identity) before proceeding.

This issue stems from the fact that the `transport_prepare` functionis "symmetrical" and tries to reduce network round-trips;  instead theclient could first wait for the server verifier and then send its own(i.e. just a minor change to that function).

Ciprian.