💾 Archived View for gemi.dev › gemini-mailing-list › 000045.gmi captured on 2023-11-04 at 12:20:34. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

-=-=-=-=-=-=-

Regarding `gemini://` over NaCL (replacing TLS)

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

So I've taken Sean Conner advice and implemented a proof-of-concept
client and server (only the protocol, transport and crypto part, not
the actual file serving) in Python by replacing TLS with NaCL /
`libsodium`.



The code is available on GitHub:

    https://github.com/cipriancraciun/gemini-experiments/blob/e4bbeae01a8e7
d2e393ab93317890f5c7f511b09/nacl/sources

The sources are structured as such:


the `gemini://` protocol;  no surprises here, the `protocol_client`
function (that takes the server's address, an optional public key
(used for NaCL signatures), and a selector) interacts with the server
and returns the body;  similarly the `protocol_server` function takes
a listening socket and a handler function (that given a selector
returns the status, meta and body) and interacts with exactly one
client;




what happens;  again more on this later;


full payloads;  it also adds support for framed send / receive by
writing a 4 bytes length, followed by a payload of that many bytes (a
well known pattern);  this basically replaces TLS segments and removes
the need of line splitting, as now each individual protocol item
(selector, status and meta, body, and the key exchanges) uses one
single frame;


state, and relies exclusively on functions that take all required
inputs as arguments;  (this way the functionality of one function can
be assessed only in terms of its inputs and outputs, thus I hope
simplifying the understanding;)  (one can think of it as almost purely
functional, with the exception of nonces and sockets which are both
mutated by successive calls to the various transport functions;)



Now regarding the transport / crypto and how it replaces TLS:


length prefixed) packets, so from now on "send" and "receive" implies
such frames;


(https://github.com/cipriancraciun/gemini-experiments/blob/e4bbeae01a8e7d2e
393ab93317890f5c7f511b09/nacl/sources/transport.py#L40-L94)
which does as follows;


transport protocol is identical, thus symmetrical;


(https://libsodium.gitbook.io/doc/key_exchange) the local peer creates
an ephemeral session public / private key pair, which it exchanges
with its remote peer;  (this is the only piece of information that
doesn't travel encrypted, and thus available to an attacker;)


above) the local peer creates two symmetric secret keys, one for
sending and one for receiving;  (by now the remote peer has done the
same and obtained exactly the same symmetric secret keys;)


remote peer, and also known by an attacker) it creates (in a
deterministic manner, thus again known by an attacker) a nonce for
received packets;  using its remote peer session public key (again
known to an attacker) it creates a nonce for sent packets;  each time
one of these nonces are used (for sending and receiving), its
respective value is incremented by 1;  (according to the cryptographic
properties described at that page, having known nonces to the attacker
is OK, the only requirement is not to reuse them;)


`crypto_secretbox`
(https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox)
which provides both encryption and authentication against tampering;
(and coupled with the unique incremental nonces, it also assures that
the messages haven't been replayed, reordered, or dropped;)


(https://libsodium.gitbook.io/doc/public-key_cryptography/public-key_signatures)
the local peer creates a signature public / private key pair used for
authentication;  (both the client and server can use a stored public
key, or generated on the fly if `None` is used);


signs with its own signature private key the remote peer's session
public key;  the local peer then exchanges with the remote peer its
own signature public key and the computed signature;  (this proves
that the local peer has control over the signature secret key, and
also that this is not a replay attack as it signs something under the
control of the remote peer;)


detached signature it verifies it accordingly;


authenticated themselves to one-another;



A few notes about this encryption scheme:


followed the best practices, especially those described in
(https://libsodium.gitbook.io/doc/secret-key_cryptography/encrypted-messages);
 (I bet an experimented cryptographer can take a look at this and say
if there are any issues, and how to fix those;)


data (i.e. the output has the same length as the input plus a fixed
constant), the length of the selector and header can be determined by
an attacker by looking at the network traffic;  adding a padding to
all packets multiple of say 128 bytes, and perhaps randomly adding one
to four such 128 bytes groups, would make these length unguessable
while impacting very little the network performance;


signature public key and signature verifier) are sent as different
`socket.send` calls, and thus perhaps as two different actual TCP
segments;  but a more efficient implementation can coalesce these into
a single `socket.send`;


payload size and latency due to round-trips (remember the protocol is
symmetric, thus this applies both to the client and server):
  * 32+4 bytes for the session public key exchange;
  * (both peers must read what was sent above before continuing, thus
one half-trip);
  * 32+16+4 bytes for the signature public key exchange;
  * 64+16+4 bytes for the signature verifier;
  * (both peers must read what was sent above before continuing, thus
another half-trip);
  * (so far a single complete round-trip was made;)
  * for each additional message an extra 16+4 bytes are sent;  (16
bytes for the `secretbox` authentication, and the 4 bytes for the
framing;)


(https://en.wikipedia.org/wiki/TCP_Fast_Open), i.e. the session public
key exchange can be done at the same time as the TCP
three-way-handshake happens;


larger than 4 GiB;  this is not a limitation, as we can implement for
the body an 8 bytes length prefixed framing;


and also the possibility of keep-alive;


frames instead of parsing for `CRLF`;


by asking the client to send with its signature public key also the
"virtual host" it wants to communicate with, thus based on that the
server can respond with that proper public key (this doesn't affect
the packet exchanges);  as opposed to TLS-SNI feature, this proposal
does not expose to an attacker the identity of the server public key
(i.e. the virtual host);  (granted there is a proposed extension to
TLS-SNI that encrypts that information;)


the transport but also for the `gemini://` semantic) that should be
sent first by the client, and based on that the server should choose
the proper implementation if supported;  (however such a feature has
to be carefully implemented as not to be used by attackers to
downgrade a certain client into a vulnerable version;)



I hope I haven't made too many mistakes, and I hope this is useful as
a proof-of-concept that one could replace TLS for such simpler
protocols,
Ciprian.

Link to individual message.

Dave Gauer <dave (a) ratfactor.com>

On 2/29/20 8:31 PM, Ciprian Dorin Craciun wrote:
> So I've taken Sean Conner advice and implemented a proof-of-concept
> client and server (only the protocol, transport and crypto part, not
> the actual file serving) in Python by replacing TLS with NaCL /
> `libsodium`.
> 
> The code is available on GitHub:
> 
>      https://github.com/cipriancraciun/gemini-experiments/blob/e4bbeae01a
8e7d2e393ab93317890f5c7f511b09/nacl/sources


Holy crap. You wrote this in the time it took me to draft a response to 
your *first* email. :-)

I just wanted to say: I like your ideas and applaud this tangible 
addition to the ecosystem.  I would personally love it something simpler 
than TLS could be used for Gemini.

I love the passion I've seen in the mailing list - it's gratifying to 
see others who care deeply about the same things I do.  My hat's off to 
all of the pioneers who have written clients, servers, and content for 
Gemini so far.

Okay, back to lurking.

(I swear I'll have something substantive to add in the future.)

-ratfactor

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> So I've taken Sean Conner advice and implemented a proof-of-concept
> client and server (only the protocol, transport and crypto part, not
> the actual file serving) in Python by replacing TLS with NaCL /
> `libsodium`.

  Wow.  For that I thank you.  Now there's something to actually look at. I
do have a few questions about the code as I'm looking over it.  Prepare for
lots of questions.  I had them for solderpunk as well.

1) I assume the 32-bit length is sent bigendian (if I understand the
argument to struct.pack() and struct.unpack() correctly---I'm not a Python
programmer).  Why big endian?  99% of all computers on the Internet today is
little endian (x86) so it seems to me that sending it little endian would be
better.  [1][2]

2) As I feared, this requires a more complicated implementation.  solderpunk
wanted a protocol that could be implemented quickly and while TLS might be a
bad protocol, it at least has the feature of being widely available and
largly transparent if done correctly (like libtls, part of LibreSSL, does). 
It handles not only the crypo portion, but the framing of data (invisibly to
the rest of the application).  To tell the truth, I don't know the actual
bytes of the TLS portion of the protcol as that is handled for me.

  In fact, that's part of why HTTPS was so successful---it doesn't change
the HTTP protocol at all.  It just slips in between TCP and HTTP and is
transparent to both.

  [ snip ]

> I hope I haven't made too many mistakes, and I hope this is useful as
> a proof-of-concept that one could replace TLS for such simpler
> protocols,

  I know that given the self-sign certificate nature of Gemini decreases
security a bit (TOFU and all that), not *all* Gemini servers are using
self-signed certificates.  There's at least two that I know of that use
actual signed certificates (from Let's Encrypt), and for my own server, I
use a signed certificate from my own CA (technically, the certificate isn't
self-signed, but the CA is self-certificed).  With a signed certificate, you
get *some* assurance that the server you are talking to is the server you
expect to be talking to, but it's still, technically, subject to a MITM
attack (either at the corporate level, or at the state level---it's way less
likely to come from some random hacker).

  What's still missing from your proof-of-concept though, is support for
client certificates.  Yes, you have the "transient" stuff working, but for
my Gemini server, I have a second that is unavailable unless you have a
signed certificate from me.  Send in a certificate request, I generate the
certificate and send that back, and you can access the sooperseecret portion
of my site [3] (no one has done that yet; then again, I haven't exactly
advertised that I would do that either).

  This way, I can control who has access to what on my Gemini server in a
mostly stateless way (I don't have to maintain a database of userids and
passwords, just pass out certificates which can be revoked if needed, and
will expire after a period of my choosing).  Yes, that complicated *my* end,
and may complicate a client that wants to support that, but it doesn't
complicate the *protocol* at all---TLS provides all the machinery for that.

  I'm still going over your code, but I'm not sure I can run it.  For one, I
don't know which version of Python (I know there are major differences
between 2 and 3 and I think I only have 2.something---I don't program in
Python) and I don't have libsodium install (but I do have NaCL).  But again,
I thank you for doing this work and giving us something tangible to look at
and run.

  -spc

[1]	Okay, I happen to agree with the big endian choice, but that's
	because I'm biased---binary based Internet protocols are all big
	endian, and I have a soft spot for the Motorola CPUs of past.  I've
	never been a fan of little endian personally.

[2]	I'm also asking to reflect back to you the same argument you
	presented with using CRLF.  Your big endian choice seems to be
	"because that's how all Internet protocols do it".

[3]	gemini://gemini.conman.org/conman-labs-private/

Link to individual message.

Bradley D. Thornton <Bradley (a) NorthTech.US>



On 3/1/2020 4:18 PM, Sean Conner wrote:
> It was thus said that the Great Ciprian Dorin Craciun once stated:
>> So I've taken Sean Conner advice and implemented a proof-of-concept
>> client and server (only the protocol, transport and crypto part, not
>> the actual file serving) in Python by replacing TLS with NaCL /
>> `libsodium`.
> 
>   Wow.  For that I thank you.  Now there's something to actually look at. I
> do have a few questions about the code as I'm looking over it.  Prepare for
> lots of questions.  I had them for solderpunk as well.
> 
> 1) I assume the 32-bit length is sent bigendian (if I understand the
> argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> programmer).  Why big endian?  99% of all computers on the Internet today is
> little endian (x86) so it seems to me that sending it little endian would be
> better.  [1][2]
> 
> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does).


um.... <smile>, Sean I have to call attention here to the fact that such
an implementation of security isn't actually as simple as you portray in
that statement, lolz...

For example, just a couple of days ago you touted the libtls that you
[were able to] took advantage of, as a result of developing GLV-1.12556
being written in Lua ;)

In fact, you posted a tiny snippet of text showing how simple it was (in
that language), lending in part, to the simplicity of a Gemini server
being possible as a result of a weekend coding and beer session.

On the other hand, I recall quite clearly, Michaels encyclopedic
lamentations on the vagaries of attempting to acheive successful results
in Python, with regards to TLS and client/transient certs, due to the
horrendous state of Python libs in that regard :)

Just sayin', yes, it's trivial because you chose (whether by design or
inadvertantly) a framework upon which to support TLS, while in practice,
the implementation for others isn't necessarily so straight-forward ;)


>   In fact, that's part of why HTTPS was so successful---it doesn't change
> the HTTP protocol at all.  It just slips in between TCP and HTTP and is
> transparent to both.


Again, you chose something other than Python3 to do this with :)


>   I know that given the self-sign certificate nature of Gemini decreases
> security a bit (TOFU and all that), not *all* Gemini servers are using
> self-signed certificates.  There's at least two that I know of that use
> actual signed certificates (from Let's Encrypt), and for my own server, I


My servers are among those :)


>   What's still missing from your proof-of-concept though, is support for
> client certificates.  Yes, you have the "transient" stuff working, but for
> my Gemini server, I have a second that is unavailable unless you have a
> signed certificate from me.  Send in a certificate request, I generate the
> certificate and send that back, and you can access the sooperseecret portion
> of my site [3] (no one has done that yet; then again, I haven't exactly
> advertised that I would do that either).

That's really kewl, but it brings to mind the notion (at least to me),
that we may be painting ourselves into a corner by specifying a method
of encryption in canon that precludes the possibility for allowing other
methods, emerging or otherwise, that might *date* the Gemini protocol's
utility moving forward.

Question: Isn't it (even if non-trivial) possible, to account for other
methods of encryption by the listening daemon, some servers being able
to secure communications by one or another method if the upcoming
clients can also support those technologies?

I'm just thinking that security is a moving, and mostly reactive, rather
than proactive target, but allowing for the adoption, in a proactive
way, for the inclusion of developing encryption methods might be a good
thing to ensure that something like Gemini isn't relegated to the
boneyard when earlier methods two decades and more are eventually
deprecated (Like true SSL was).


>   I'm still going over your code, but I'm not sure I can run it.  For one, I

I have no idea whether Ciprian's proof of concept can translate into
viable solutions, but I'm confident that if anyone can competently
evaluate the pros and cons of what he's suggesting - it is you my friend :)


-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268

Link to individual message.

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

On Mon, Mar 2, 2020 at 2:18 AM Sean Conner <sean at conman.org> wrote:
> 1) I assume the 32-bit length is sent bigendian (if I understand the
> argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> programmer).  Why big endian?  99% of all computers on the Internet today is
> little endian (x86) so it seems to me that sending it little endian would be
> better.  [1][2]
>
> [1]     Okay, I happen to agree with the big endian choice, but that's
>         because I'm biased---binary based Internet protocols are all big
>         endian, and I have a soft spot for the Motorola CPUs of past.  I've
>         never been a fan of little endian personally.
>
> [2]     I'm also asking to reflect back to you the same argument you
>         presented with using CRLF.  Your big endian choice seems to be
>         "because that's how all Internet protocols do it".


There are a couple of reasons I like big endian for protocols:


you've observed in [2]) most other protocols are big endian, thus
there is a lot of tooling for this;  (for example Erlang even has
built-in functions for this;)


little endian on x86, when we write numbers in code we use "big
endian";


"surprises", I read the number left to right, and if I just take the
bytes in hex and concatenate them I can get the constant, i.e. `[01 02
03 04]` is just `0x01020304`;




> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does).


The current proof-of-concept in Python I've presented is "feature
complete" in terms of what the current `gemini://` specification
requires;  except perhaps the certificate validation, but the specs
says it should be handled SSH-like.

My take on this is:  if we have a clear specification about what we
require from the transport layer, then we can come-up with a design
and implementation that provides it, nothing more.  At the moment the
`gemini://` specification requires nothing more than what I've
implemented.




> It handles not only the crypo portion, but the framing of data (invisibly to
> the rest of the application).  To tell the truth, I don't know the actual
> bytes of the TLS portion of the protcol as that is handled for me.


Here I want to argue that you are wrong on the following accounts:


"byte streams") which it calls TLS records;  (though these
unfortunately are limited to 16 KiB);


this to the applications, although it warns the user in the man-page;
however if one calls `SSL_read` with a large enough buffer, at most
one record will be read at one time:

~~~~
https://www.openssl.org/docs/man1.0.2/man3/SSL_read.html

SSL_read() works based on the SSL/TLS records. The data are received
in records (with a maximum record size of 16kB for SSLv3/TLSv1). Only
when a record has been completely received, it can be processed
(decryption and check of integrity). Therefore data that was not
retrieved at the last call of SSL_read() can still be buffered inside
the SSL layer and will be retrieved on the next call to SSL_read(). If
num is higher than the number of bytes buffered, SSL_read() will
return with the bytes buffered. If no more bytes are in the buffer,
SSL_read() will trigger the processing of the next record. Only when
the record has been received and processed completely, SSL_read() will
return reporting success. At most the contents of the record will be
returned. As the size of an SSL/TLS record may exceed the maximum
packet size of the underlying transport (e.g. TCP), it may be
necessary to read several packets from the transport layer before the
record is complete and SSL_read() can succeed.
~~~~

Thus the TLS framing is not "invisible" to the application, it just
can be safely ignored.

Thus most applications will build yet-another-framing-mechanism on-top
of TLS.  (Just because `gemini://` and other protocols use lines ended
by `CRLF` doesn't mean these aren't "frames", i.e. one frame is a
sequence of one or multiple bytes followed by exactly one `CRLF` or
perhaps `LF` or perhaps `CR` or perhaps `LFCR`.)


That is why in my protocol proposal we don't need the `CRLF` framing
any more, because we rely on the transport layer to both apply the
framing and do the crypto.




>   In fact, that's part of why HTTPS was so successful---it doesn't change
> the HTTP protocol at all.  It just slips in between TCP and HTTP and is
> transparent to both.


OK, just because HTTPS was "so successful" doesn't mean we need to
copy it one-to-one.  In case of HTTPS the TLS layer "just slips in
between HTTP and TCP" because it was an afterthought, and everybody
wanted a quick solution, either in terms of TLS offloading / proxy and
other "hacks".

On the other side a lot of HTTPS security issues stemmed from this
ignorance of TLS, like for example cookie leaks due to TLS
compression, etc.

Thus my position is that a secure protocol can't be designed by
ignoring the actual layer providing the "security"...




>   [ snip ]
>
> > I hope I haven't made too many mistakes, and I hope this is useful as
> > a proof-of-concept that one could replace TLS for such simpler
> > protocols,
>
>   I know that given the self-sign certificate nature of Gemini decreases
> security a bit (TOFU and all that), not *all* Gemini servers are using
> self-signed certificates.  There's at least two that I know of that use
> actual signed certificates (from Let's Encrypt), and for my own server, I
> use a signed certificate from my own CA (technically, the certificate isn't
> self-signed, but the CA is self-certificed).  With a signed certificate, you
> get *some* assurance that the server you are talking to is the server you
> expect to be talking to, but it's still, technically, subject to a MITM
> attack (either at the corporate level, or at the state level---it's way less
> likely to come from some random hacker).


Strictly regarding TLS certificates, my "security" of and "trust" in a
site protected with a proper TLS certificate is proportional to the
amount of effort that is required to:

the last year or two, one is able to social engineer someone at the
company to validate the issuance of a certificate;

last three months, one was able to hijack or spoof either the DNS,
either the IP behind the domain I'm accessing, and thus validate the
issuance of a certificate;

Thus, personally I don't put a lot of weight in these certificates for
important stuff, instead I put faith in the various "extra checks" the
web and browsers community have implemented, from HTTPS certificate
pinning, to hard-coded certificates in browsers (for Google domains
for example), etc.


So in the end I think the `gemini://` design team should take a decision:

SSH-like;  (and keep things simple;)

done with various certificate related verifications outside the X.509
standard;)


So if `gemini://` wants to be simple and secure, I would say a mix of
the first two.




>   What's still missing from your proof-of-concept though, is support for
> client certificates.  Yes, you have the "transient" stuff working, but for
> my Gemini server, I have a second that is unavailable unless you have a
> signed certificate from me.  Send in a certificate request, I generate the
> certificate and send that back, and you can access the sooperseecret portion
> of my site [3] (no one has done that yet; then again, I haven't exactly
> advertised that I would do that either).


On the contrary, the my current protocol does have support for
"permanent" client certificates, as they are just a special case of
"transient" ones;  just:

self-signed document proving that you have access to the secret key
bound to that public key, and perhaps additional information), send
the public key;

`~/.ssh/authorized_keys`;

Sure, now you'll say that with a proper TLS client certificate you
don't need to store it on your server, because you can just verify
that it has a proper signature from your own CA.  However how do you
revoke such a certificate?  You create a CRL which you store in a
file.

Thus in case of TLS you still need to maintain a "blacklist", while in
my simpler proposal you need to maintain a "whitelist".  :)




My take on the whole "certificates" would be this:  given that
`gemini://` wants to be simple, let's also keep the crypto stuff
simple;  i.e. no "certificates", just like in case of SSH public /
private keys.




> [...]  Yes, that complicated *my* end,
> and may complicate a client that wants to support that, but it doesn't
> complicate the *protocol* at all---TLS provides all the machinery for that.


Because `gemini://` mandates the usage of TLS, I think it's unfair to
treat TLS as "not part of the protocol";  you can ignore that it
exists, but that is counter-productive I think.




>   I'm still going over your code, but I'm not sure I can run it.  For one, I
> don't know which version of Python (I know there are major differences
> between 2 and 3 and I think I only have 2.something---I don't program in
> Python) and I don't have libsodium install (but I do have NaCL).  But again,
> I thank you for doing this work and giving us something tangible to look at
> and run.

You need Python 2.7 and I would suggest creating a virtualenv.  The
only dependency I used is `pysodium` which requires `libsodium`.  (All
the commands I run are written in the `z-run` file, which I think is
self-explanatory.)

Ciprian.

Link to individual message.

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

On Mon, Mar 2, 2020 at 10:36 AM Bradley D. Thornton
<Bradley at northtech.us> wrote:
> Question: Isn't it (even if non-trivial) possible, to account for other
> methods of encryption by the listening daemon, some servers being able
> to secure communications by one or another method if the upcoming
> clients can also support those technologies?


This is exactly what happened with SSL (at least two versions) which
coexisted alongside with TLSv1.0, which then together coexisted
alongside with TLSv1.1, which then all together coexisted with
TLSv1.2, which now all coexist with TLSv1.3;  and although everybody
screams that anything under TLSv1.2 is "broken", we still haven't
dropped support for TLSv1.1...  :)

My take is having "options" is good for "complex" things, however for
simple things, like `gemini://` strives to be, having one "good-enough
but simple" solution is the best.


So if I were to vote I would say:

client sends in the first packet (even before encryption), and the
server must match or error out;  (we need to make sure that after the
encryption is established, this "version" is re-confirmed, so that we
aren't vulnerable to protocol downgrade attacks;)

`gemini://` protocol versions;  (i.e. the current "stable", the
previous "stable", and the "long-term-support" one;)

Ciprian.

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Bradley D. Thornton once stated:
> On 3/1/2020 4:18 PM, Sean Conner wrote:
> > 
> > 2) As I feared, this requires a more complicated implementation.  solderpunk
> > wanted a protocol that could be implemented quickly and while TLS might be a
> > bad protocol, it at least has the feature of being widely available and
> > largly transparent if done correctly (like libtls, part of LibreSSL, does).
> 
> um.... <smile>, Sean I have to call attention here to the fact that such
> an implementation of security isn't actually as simple as you portray in
> that statement, lolz...
> 
> For example, just a couple of days ago you touted the libtls that you
> [were able to] took advantage of, as a result of developing GLV-1.12556
> being written in Lua ;)
> 
> In fact, you posted a tiny snippet of text showing how simple it was (in
> that language), lending in part, to the simplicity of a Gemini server
> being possible as a result of a weekend coding and beer session.
> 
> On the other hand, I recall quite clearly, Michaels encyclopedic
> lamentations on the vagaries of attempting to acheive successful results
> in Python, with regards to TLS and client/transient certs, due to the
> horrendous state of Python libs in that regard :)

  Do you have any links to this?  I don't remember seeing any of that, and
I'd be interested in reading it.

> Just sayin', yes, it's trivial because you chose (whether by design or
> inadvertantly) a framework upon which to support TLS, while in practice,
> the implementation for others isn't necessarily so straight-forward ;)

  By design.  I knew libtls, written by the OpenBSD people, was designed to
make using TLS simple to use, and hard to use incorrectly.  Since my prerred
language is Lua, it was a simple matter to wrap up libtls for use in Lua
and a moderate amount of work to get it working within a network event
driver.  I happen to agree with the OpenBSD guys that *using* crypto is too
hard.

  I'm just sad that libtls doesn't seem to get much use.  But it could be
that I haven't looked hard enough.  I don't know.
  
> Question: Isn't it (even if non-trivial) possible, to account for other
> methods of encryption by the listening daemon, some servers being able
> to secure communications by one or another method if the upcoming
> clients can also support those technologies?

  In general?  Yes.  In practice, with current implementations of TLS?  I
don't know, I haven't looked into it.

  But to remind you, I'm not the one who developed the Gemini protocol.

  -spc

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Mon, Mar 2, 2020 at 10:36 AM Bradley D. Thornton
> <Bradley at northtech.us> wrote:
> > Question: Isn't it (even if non-trivial) possible, to account for other
> > methods of encryption by the listening daemon, some servers being able
> > to secure communications by one or another method if the upcoming
> > clients can also support those technologies?
> 
> 
> This is exactly what happened with SSL (at least two versions) which
> coexisted alongside with TLSv1.0, which then together coexisted
> alongside with TLSv1.1, which then all together coexisted with
> TLSv1.2, which now all coexist with TLSv1.3;  and although everybody
> screams that anything under TLSv1.2 is "broken", we still haven't
> dropped support for TLSv1.1...  :)

  Because dropping support would make too many people scream.  As I told a
VP of the company I work for, "it doesn't make sense for our department to
have two week sprints when our customer [the Monopolistic Phone Company] has
two year sprints!" It took five years just to get a flag we needed added to
a message. [1]

  -spc

[1]	We were able to work around it, but it wasn't pretty.

Link to individual message.

Sean Conner <sean (a) conman.org>


  I think I'm going to bow out of the encryption talk.  It's clear to me
that I feel TLS is good enougn, and Ciprian doesn't (or would rather have
alternatives).  I'm not the creator of the Gemini protocol, so I don't have
the authority to make drastic changes to the protocol.

  I've heard the admonintion to not roll your own crypto, and I believe that
it extends to protocols as well.  And as bad and complex as TLS might be,
it's a standard, there are real cryptographers trying to break it, and there
are multiple implementations of it available: OpenSSL and LibreSSL are two,
but off the top of my head, there are also bearSSL, PolarSSL, boringSSL. and
GNUTLS.  And in a sense, that makes it easier to use, since these
implementations *exit*.  This new protocol Ciprian is designing hasn't been
vetted, and I'm unaware of anyone on this list that is expert enough in
crypto to fully examine it.

  And Ciprian wants to design a new secure protocol ... 

  Anyway, a few comments about this message.

It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Mon, Mar 2, 2020 at 2:18 AM Sean Conner <sean at conman.org> wrote:
> > 1) I assume the 32-bit length is sent bigendian (if I understand the
> > argument to struct.pack() and struct.unpack() correctly---I'm not a Python
> > programmer).  Why big endian?  99% of all computers on the Internet today is
> > little endian (x86) so it seems to me that sending it little endian would be
> > better.  [1][2]
> >
> > [1]     Okay, I happen to agree with the big endian choice, but that's
> >         because I'm biased---binary based Internet protocols are all big
> >         endian, and I have a soft spot for the Motorola CPUs of past.  I've
> >         never been a fan of little endian personally.
> >
> > [2]     I'm also asking to reflect back to you the same argument you
> >         presented with using CRLF.  Your big endian choice seems to be
> >         "because that's how all Internet protocols do it".
> 
> There are a couple of reasons I like big endian for protocols:
> 
> * it is logical;  for example although all integers are stored in
> little endian on x86, when we write numbers in code we use "big
> endian";

  We use the Arabic numerals these days.  It's interesting to note that the
value three hundred and twenty-one is written in the order of 321 in Arabic
(much like in Western countries) but Arabic itself is written right-to-left,
so one could say they write their numbers in little endian format.  You're
just expressing a western bias---logic has nothing to do with it 8-P

> * (and most importantly) when dumping a protocol capture there are no
> "surprises", I read the number left to right, and if I just take the
> bytes in hex and concatenate them I can get the constant, i.e. `[01 02
> 03 04]` is just `0x01020304`;

  And it'd be backwards for Arabic programmers.

  -spc

Link to individual message.

Michael Lazar <lazar.michael22 (a) gmail.com>

> It was thus said that the Great Bradley D. Thornton once stated:
> > On 3/1/2020 4:18 PM, Sean Conner wrote:
> > >
> > > 2) As I feared, this requires a more complicated implementation.  solderpunk
> > > wanted a protocol that could be implemented quickly and while TLS might be a
> > > bad protocol, it at least has the feature of being widely available and
> > > largly transparent if done correctly (like libtls, part of LibreSSL, does).
> >
> > um.... <smile>, Sean I have to call attention here to the fact that such
> > an implementation of security isn't actually as simple as you portray in
> > that statement, lolz...
> >
> > For example, just a couple of days ago you touted the libtls that you
> > [were able to] took advantage of, as a result of developing GLV-1.12556
> > being written in Lua ;)
> >
> > In fact, you posted a tiny snippet of text showing how simple it was (in
> > that language), lending in part, to the simplicity of a Gemini server
> > being possible as a result of a weekend coding and beer session.
> >
> > On the other hand, I recall quite clearly, Michaels encyclopedic
> > lamentations on the vagaries of attempting to acheive successful results
> > in Python, with regards to TLS and client/transient certs, due to the
> > horrendous state of Python libs in that regard :)
>
>   Do you have any links to this?  I don't remember seeing any of that, and
> I'd be interested in reading it.

I believe this is referencing this post that I made a while ago [1].

Personally, I would rather have gemini:// not be encrypted at all. I know
there is a subset of privacy conscious users who are super dogmatic about
security and E2E encryption. This much is clear from watching the gopher
community. But I am not one of those users, and that is not what excites me
about the gemini protocol.

[1] gemini://mozz.us/journal/2019-08-21_transient_tls_certs.gmi

- mozz

Link to individual message.

Sean Conner <sean (a) conman.org>

It was thus said that the Great Michael Lazar once stated:
> > It was thus said that the Great Bradley D. Thornton once stated:
> > > >
> > > On the other hand, I recall quite clearly, Michaels encyclopedic
> > > lamentations on the vagaries of attempting to acheive successful results
> > > in Python, with regards to TLS and client/transient certs, due to the
> > > horrendous state of Python libs in that regard :)
> >
> >   Do you have any links to this?  I don't remember seeing any of that, and
> > I'd be interested in reading it.
> 
> I believe this is referencing this post that I made a while ago [1].

  Ah, thanks.

  I'm beginning to think it's a shame that libtls isn't used more often.  I
know of only one other TLS implementation that has implemented libtls, and
that's bearTLS (which hasn't implemented everything in libtls as of yet).
It really does make using encryption with TLS easier.

> Personally, I would rather have gemini:// not be encrypted at all. I know
> there is a subset of privacy conscious users who are super dogmatic about
> security and E2E encryption. This much is clear from watching the gopher
> community. But I am not one of those users, and that is not what excites me
> about the gemini protocol.

  I hear you.  I'm not overly fond of the whole "encrypt all the things"
movement myself.    But hey, the only constant is change.

> [1] gemini://mozz.us/journal/2019-08-21_transient_tls_certs.gmi

  -spc

Link to individual message.

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

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

(Although I think the change of adopting anything besides TLS is
closer 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 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.)




>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:

  https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

  https://ciphersuite.info/cs/TLS_CHACHA20_POLY1305_SHA256

Lets Encrypt;

These options are also suggested by both Mozilla and CloudFlare:





#### About the noise protocol

I've glossed over the Noise protocol specification, however before
getting into that I've read the first link bellow:



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.)


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):



(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.

Link to individual message.

solderpunk <solderpunk (a) SDF.ORG>

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.
>

Link to individual message.

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

On Tue, Mar 3, 2020 at 2:20 PM Ciprian Dorin Craciun
<ciprian.craciun at gmail.com> wrote:
> ####  The part about other alternatives
>
> I've found the following project that also does a "state-of-the-art"
> analysis (though granted in 2015):


Another interesting approach is CurveCP (designed by Daniel J. Bernstein):


However it has a few drawbacks:

of the server;

On the flip side, especially looking at the packets document, the
specification is extremely simple, both to understand and implement.
(The most complex part of that specification is the nonces
handling...)




> ####  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.


In the interim I've reversed engineered the crypto primitives used by
`libsodium` (it wasn't hard, but I had to do it):


umentation/libsodium-internals.md


Then I've created a nice diagram of what happens in the proposed protocol:


umentation/diagrams/protocol-v1.png

umentation/diagrams/protocol-v1.svg




> 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.

I've "fixed" that by making the server authenticate itself first.


Next I'll try to submit this proposal to a cryptographers community to
receive some feedback.

Ciprian.

Link to individual message.

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

On Tue, Mar 3, 2020 at 9:16 PM solderpunk <solderpunk at sdf.org> wrote:
> 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.


Can I still keep this thread "open", at least to give a "theoretical"
alternative?  (Just talking about the alternative, although not using
it, could give us an insight of what might be nice to have in a future
iteration.)

(I don't think I'll be posting much on this, except after I get some
feedback from the cryptographers community.)




> 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.

It's not like there are hundreds of client and server implementations...  :)




> 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.


This is perhaps true;  although as said, with strong consensus, I
don't think that would happen.

Ciprian.

Link to individual message.

solderpunk <solderpunk (a) SDF.ORG>

On Tue, Mar 03, 2020 at 09:34:03PM +0200, Ciprian Dorin Craciun wrote:
 
> Can I still keep this thread "open", at least to give a "theoretical"
> alternative?  (Just talking about the alternative, although not using
> it, could give us an insight of what might be nice to have in a future
> iteration.)
> 
> (I don't think I'll be posting much on this, except after I get some
> feedback from the cryptographers community.)

As long as it's a reasonable amount of traffic, sure.
 
> > 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.
> 
> It's not like there are hundreds of client and server implementations...  :)

Well, no, but it's not like there's 1 or 2 either.
 
Cheers,
Solderpunk

Link to individual message.

Jason McBrayer <jmcbray (a) carcosa.net>

Sean Conner <sean at conman.org> writes:

> It was thus said that the Great Ciprian Dorin Craciun once stated:
>> So I've taken Sean Conner advice and implemented a proof-of-concept
>> client and server (only the protocol, transport and crypto part, not
>> the actual file serving) in Python by replacing TLS with NaCL /
>> `libsodium`.

> 2) As I feared, this requires a more complicated implementation.  solderpunk
> wanted a protocol that could be implemented quickly and while TLS might be a
> bad protocol, it at least has the feature of being widely available and
> largly transparent if done correctly (like libtls, part of LibreSSL, does). 
> It handles not only the crypo portion, but the framing of data (invisibly to
> the rest of the application).  To tell the truth, I don't know the actual
> bytes of the TLS portion of the protcol as that is handled for me.

If we really wanted to go down this route, Noise protocol is more
comparable to TLS than just using NaCL directly; the Python bindings
seem only about as complex to use as the Python TLS bindings. The only
thing is that Noise has libraries for 5 or 6 languages, compared to how
ubiquitous TLS is.

-- 
Jason McBrayer      | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
                    | but stranger still is lost Carcosa.?
                    | ? Robert W. Chambers,The King in Yellow

Link to individual message.

Ciprian Dorin Craciun <ciprian.craciun (a) gmail.com>

On Tue, Mar 10, 2020 at 3:55 PM Jason McBrayer <jmcbray at carcosa.net> wrote:
> If we really wanted to go down this route, Noise protocol is more
> comparable to TLS than just using NaCL directly; the Python bindings
> seem only about as complex to use as the Python TLS bindings. The only
> thing is that Noise has libraries for 5 or 6 languages, compared to how
> ubiquitous TLS is.


In the interim I've documented my proposal, including a clear diagram,
used functions from libsodium and an asessment:

umentation/protocol-v1.md

umentation/libsodium-internals.md


Now, regarding the Noise protocol, as you've observed there aren't
many implementations of it;  however on the other side the Noise
protocol is actually a "blueprint" of how to implement secure
communication protocols and doesn't actually specify any cryptographic
primitives;  thus all the existing libraries are either incompatible
with each other or are quite uninteligible (I've looked at a few
Rust-based implementations and I wouldn't know where to start using
them).

On the other side my proposal was to get "inspired" from the Noise
protocol, and then try to provide a simple and clear "recipe" based on
that.


Ciprian.

Link to individual message.

---

Previous Thread: Is it too late to consider adding a subset of Markdown to the render spec?

Next Thread: [SPEC-CHANGE] Preformatted text, header and unordered list lines defined