TLS certificate sizes in Geminispace

[Sean Conner]

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.  As I said to
defdefred, people are forgetting that TCP *itself* has overhead.  More on
that below.

> Some of it is
> network based, to do with actually downloading the certificate, and
> doing the handshake.  Some of it is computation based, to do with the
> key exchange calculations.  Which is the more important bottleneck will
> differe between applications.  In cases where network overhead is more
> important, getting down the size of the certificate may help.
> 
> My AV-98 TOFU database has 103 certificates stored in it.  The mean size
> is 1247 bytes - about as large, IIRC, as the average text/gemini
> document.  95% of certificates range in size between 704 bytes and 1634
> bytes.

  How are they stored?  If they look like this:

-----BEGIN CERTIFICATE-----
MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
...

then your figures are a bit high---the certificate is *not* transmitted as
base-64 encoded data, so unless you took that into account, your figures are
on the high side.

  And as I'm wont to do, I did a deep dive into this.  I made a request to
<gemini://gemini.conman.org/> to obtain the 2,633 byte file, and I captured
it with wireshark.  Here is the packet-by-packet replay of that exchange.

		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)

  One implementation quirk GLV-1.12556 has is that before it serves up any
data, it ensures that the complete TLS handshake has finished---I do that to
ensure the client certificate (if any) is available but I could probably try
moving that out of the "happy no-certificate path".  Anyway ...

  Half the packets involved are simply TCP overhead, no data of any type is
sent.  The first three packets are larger than the minimum 40 bytes due to
TCP options being sent, and the largst packet size availble is 1492, due to
limititaions on Ethernet.  And just for completeness, here's a gopher
request to a file of similar size (<gopher://gopher.conman.org/>, 2,413
bytes):

		size direction
	1	60 ->		SYN packet to server (no data)
	2	60 <-		SYN + ACK from server (no data)
	3	52 ->		ACK from client (no data)
	4	54 ->		request to server
	5	52 <-		ACK from server (no data)
	6	1492 <-		data from server
	7	52 ->		ACK from client (no data)
	8	1039 <-		data from server
	9	52 ->		ACI from client (no data)
	10	52 <-		FIN from server (no data)
	11	52 ->		FIN from client (no data)
	12	52 <-		ACK from server (no data)

  Here, 75% of the packets are pure TCP overhead, but it is 60% of the
packets of the TLS request.  I'm leaving it as an exercise for the reader to
compare the actual byte counts between the two requests.  

  And as far as removing the TCP overhead, good luck with *that!*  I'd love
to see the solution ...

  -spc