Phil Leblanc philanc at gmail.com
Tue Mar 9 17:36:52 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Tue, Mar 9, 2021 at 7:58 AM Stephane Bortzmeyer <stephane at sources.org> wrote:
On Mon, Mar 08, 2021 at 11:35:19PM +0100,
nothien at uber.space <nothien at uber.space> wrote
Firstly, most Gemini documents are (intentionally) pretty tiny,
fitting within maybe 1 or 2 KB.
Fact-checking
<gemini://gemini.bortzmeyer.org/software/lupa/stats.gmi>:
50% of the Gemtext resources are 1,099 bytes or less
Your stats.gmi page is a great resource for this issue (among others).Very cool! Thanks for making it available.
Length-analysis prevention is not Gemini's job, it's the job of TLS.
TLS cannot do it alone, and this is why it is opt-in. Padding without
knowledge of the application is dangerous.
Given your current stats, the record padding value I suggestedpreviously (4,096) would be enough to almost eliminate the risk formore than 80% of pages and significantly reduce the risk for more than90% of pages. -- and we can agree that the one 903,321 bytes document_will_ probably be catched whatever the record padding :-)
In conclusion, it's not Gemini's responsibility to handle these kinds of
attacks.
I disagree.
I agree with you disagreeing! :-) but I think Nothien means it is notthe responsibility of the Gemini _protocol_ to handle these attacks.It should rather be the responsibility of Gemini capsule owners toconfigure reasonable record padding for the typical documents theypublish.
So I think record padding belongs more to a best practices documentthan to the spec.
Just writing this, I am wondering... with TLS 1.3, can the _client_request record padding for the server response? I will check. If itcan, at least a client could take the initiative and protect itselfeven if the server does no padding,
Cheers
Phil