TLS certificate sizes in Geminispace

[Meff]

I, personally, feel that TLS is an incontrovertible part of the appeal 
of Gemini to me
(I've been using Gopher for my own personal things that I want to serve 
_without_ TLS),
but I think there should be guidance on selecting TLS parameters. I've 
run some load tests
and generated some pretty graphs for different generated keys and using 
them with both
Jetforce and Molly Brown, and there is certainly low hanging fruit to 
work on. If folks
are interested, I can collect some of my tests, data, and Python 
analysis and I can
put them up in a digestible post.

- meff

On 6/26/20 3:37 PM, solderpunk wrote:
> On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote:
>> It was thus said that the Great solderpunk once stated:
>>> There are several contributing factors to TLS overhead.
>>    I think some of the overhead concern is overblown.
> Oh, I completely agree.  It seems to bother a lot of people so I've been
> pointing out comparatively quick and easy things we could do without
> changing the spec at all to address it, because I'd much rather do that
> than increase complexity or reduce security.  But my personal experience
> using AV-98 is that browsing Geminispace feels plenty snappy enough as is.
> Especially relative to how long the content takes to consume.
>
>>    How are they stored?  If they look like this:
>>
>> -----BEGIN CERTIFICATE-----
>> MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
>> MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
>> A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
>> ...
>>
>> then your figures are a bit high
> They're DER encoded binary files, so no worries about that.
>
>> 		size direction
>> 	1	60 ->		SYN packet to server (no data)
>> 	2	60 <-		SYN + ACK from server (still no data)
>> 	3	52 ->		ACK from client (still no data)
>> 	4	203 ->		initial client TLS request
>> 	5	52 <-		ACK from server (no data)
>> 	6	1492 <-		server certificate
>> 	7	52 ->		ACK from client (no data)
>> 	8	611 <-		TLS? unsure from this point on
>> 	9	52 ->		ACK from client (no data)
>> 	10	144 ->		data
>> 	11	52 <-		ACK from server (no data)
>> 	12	95 <-		data
>> 	13	102 ->		data
>> 	14	1492 <-		data (I'm assuming by now this is the file)
>> 	15	1282 <-		data (probably more file)
>> 	16	52 ->		ACK from client (no data)
>> 	17	75 <-		getting ready to close?
>> 	18	75 ->		getting ready to cloes?
>> 	19	52 ->		FIN + ACK from client (no data)
>> 	20	46 <-		FIN from server (no data)
> Thanks for this, very enlightening!
>
> Cheers,
> Solderpunk