It was thus said that the Great Ciprian Dorin Craciun once stated:
> On Sat, Feb 29, 2020 at 1:42 AM Sean Conner <sean at conman.org> wrote:
> > True, but there's the 800-pound gorilla to consider---Windows. On
> > Windows, a call like:
> > [...]
> >
> > So there's a lot of protocols defined for the Internet that use CRLF.
> > Could a switch be made to just LF? Sure. It's also about as likely as the
> > Internet byte order being switched from big-endian to little-endian.
>
>
> OK, I'll drop the CRLF thing, but I find it odd that the only argument
> to this is "because systems and protocols designed many years ago did
> this (i.e. CRLF)", and to that you add "but anyway, all these systems
> just ignore all that and behave internally like it wasn't so (i.e.
> convert CRLF into LF)"...
I have support to check for both CRLF and LF because I do quite a bit of
work with existing Internet protocols (which define the use of CRLF) and do
extensive testing with Unix (which defines only using LF) and it makes my
life easier to support both [1]. Besides, I think you are underestimating
the extent of Windows development out there, and I think (I can't prove)
that it's easier for a programmer under Unix to add the '\r' than it would
be for a Windows programmer to force Windows *not* to add the '\r'.
> > The linked page just talks about an API for signing and ecrypting data.
> > It says nothing about negotiating the cipher, key size, or anything remotely
> > like a protocol.
>
> (I have a hunch that you are not "acquainted" with NaCL / `libsodium`;
No, I'm aware of both NaCL (which as I stated before, I have installed on
my home system) and libsodium (which I haven't installed, having NaCL
already installed).
> the short story is this: the designers of NaCL (again including
> Daniel J. Bernstein) wanted to design and implement a secure, simple
> to use, high level cryptographic library, that makes all the choices
> for its users, so that ciphers, key sizes, padding, nonces, etc.,
> aren't required to be handled by the user, and thus no mistakes would
> be made on this front.)
Yes, and I just found the Lua module I wrote for NaCL (*not* libsodium)
back in 2013 when I was last playing around with it.
> In fact that link does say at the end under the section `Algorithm
> details` what happens behind the scenes:
>
> ~~~~
> Sealed boxes leverage the crypto_box construction (X25519, XSalsa20-Poly1305).
>
> The format of a sealed box is:
>
> ephemeral_pk || box(m, recipient_pk, ephemeral_sk,
> nonce=blake2b(ephemeral_pk || recipient_pk))
> ~~~~
I was going by what I recalled of NaCL, written by the highly esteemed Dr.
Daniel J. Bernstein, of having to make *some* choices in what underlying
function to use for encryption and being a bit concerned that the entirety
of NaCL had to be included in the Lua module due to linking issues [4].
> > I would ask that if you feel this strongly about it, *do
> > it!* Implement a client and server that uses these alternative crypto
> > systems and then we'll have something to talk about.
>
> What is the chance you'll change your mind about TLS? 0.01%?
Right now? Sounds about right. If you provide some "proof-of-concept"
that can be looked at? It goes up.
> Are you
> actually considering to compare TLS vs another proposal without bias
> towards "legacy `gemini://` implementations currently using TLS"?
What I'm considering is "Hey! We should implement my great idea! And by
'we' I mean, someone else!" vibe I get when arguments like this pop up [5].
> > You can argue for an idea. But an idea *and an implementation* is
> > stronger than just the idea. I think that's why my Gemini server is so
> > featureful---I went ahead and implemented my ideas to help argue for/against
> > ideas, or even to just present *something* to talk about (when I have no
> > opinion one way or the other).
>
> Perhaps I'll throw a proof-of-concept in Python or Go. (Although as
> said above, I think it won't change anything, as there is already a
> lot of "investment" in TLS...)
So let me show you how much investment it took me to use TLS for my Gemini
server:
local tls = require "org.conman.nfl.tls"
local function main(ios) -- main routine to handle a request
local request = ios:read("*l") -- mimics the Lua file IO API
-- rest of code
end
local okay,err = tls.listen(CONF.network.addr,CONF.network.port,main,function(conf)
conf:verify_client_optional()
conf:insecure_no_verify_cert()
return conf:cert_file(CONF.certificate.cert)
and conf:key_file (CONF.certificate.key)
and conf:protocols("all")
end)
That's it. [6] Granted, I think I had an easier time of it than some
others because of the library I picked (libtls, which makes using TLS very
easy). If the other non-TLS options are this easy then you might have a
case. As solderpunk said, there are many, many, libraries and modules
available for the most popular languages for TLS. And "ease of
implementation" was one of the goals of Gemini. If these alternatives to
TLS are just as easy to use, then a proof-of-concept should show that,
right?
And for an indication of how easy it is for me to use TLS, a hypothetical
TCP-only version of Gemini would look very similar:
local tcp = require "org.conman.nfl.tcp"
local function main(ios)
local request = ios:read("*l")
-- rest of code
end
local okay,err = tcp.listen(CONF.network.addr,CONF.network.port,main)
No other changes (except to remove the code to check for user
certificates) would be required. That's how easy it should be.
> > It's easy enough to add machine readable annotations to HTML. Heck, there
> > are plenty of semantic tags in HTML to help with machine readability. Yet
> > why don't more people hand-code HTML? Why is Markdown, which, I will add,
> > has no defined way of adding metadata except by including HTML, so popular?
>
> I don't know where the HTML micro-formats popped out in this
> discussion, as I advocated against this approach. :)
Machine readable formats, or at least, machine readable bits.
> > > I'm not advocating for RDF (it was quite convoluted) or semantic web,
> > > or GraphQL, etc. I'm just advocating something better than the Gopher
> > > map.
> >
> > Okay, create a format and post it. That's the best way to get this
> > started.
>
> OK, I'll try to take a stab at that. (Although like in the case of
> TLS, I think there is already too much "investment" in the current way
> things are done.)
Dude, have you *read* the thread about text formatting? Literally half
the messages to this list have been about that, and we're *still* talking
about it.
> > Again, what's stopping you from just doing it? Waiting for consensus?
>
> Yes, a little bit of consensus won't hurt anybody... Else we end-up
> with TLS transient client certificates that act like cookies and which
> require about 2 or 3 separate status codes to signal their
> management... :)
Touch?.
-spc
[1] Okay, I have code that parses SIP messages [2]. As defined by many
(many, many) RFCs, the transport over IP requires handling of CRLF.
But test the parser, it's easier to support just LF, since the
testing I do is all under Unix [3].
I also have code that deals with email messages, again, which are
defined with CRLF, but on Unix, usually end with just LF.
[2] At work. At home, I don't have to deal with the horrors of SIP.
[3] No Windows at all at home, or at work.
[4] I can go over this in detail if you wish, but I'd rather not as it
gets rather deep rather quickly.
[5] It happens quite regularly on the Lua mailing list I'm on. So much
so that I outright ignore several people on that list.
[6] Okay, it took a bit to write the Lua module around libtls (from
LibreSSL), and some work to adapt it to my socket framework, but now
that that is done, other people can leverage that work.
---
Previous in thread (10 of 17): 🗣️ Ciprian Dorin Craciun (ciprian.craciun (a) gmail.com)
Next in thread (12 of 17): 🗣️ Bradley D. Thornton (Bradley (a) NorthTech.US)