Phil Leblanc <philanc at gmail.com> wrote:
> Given your current stats, the record padding value I suggested
> previously (4,096) would be enough to almost eliminate the risk for
> more than 80% of pages and significantly reduce the risk for more than
> 90% of pages. -- and we can agree that the one 903,321 bytes document
> _will_ probably be catched whatever the record padding :-)
Do you mean "rounding up" (by adding padding) all sent data to 4,096
bytes? I agree, that should do quite well to hide most Gemini data.
> > > 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 not
> the responsibility of the Gemini _protocol_ to handle these attacks.
> It should rather be the responsibility of Gemini capsule owners to
> configure reasonable record padding for the typical documents they
> publish.
Yep, that's what I mean. Thank you putting that to words neatly.
> Just writing this, I am wondering... with TLS 1.3, can the _client_
> request record padding for the server response?
Reading the TLS 1.3 spec[1], it appears not. Oh well.
[1]: https://tools.ietf.org/html/rfc8446#section-5.4
P.S: I've been thinking about all the issues we've come across with TLS,
and I've been collecting ideas for a new transport security protocol. I
know ~spc's stance on crypto ("get it approved by the crypto community,
make an implementation, then we'll talk"), and I'm not saying we should
switch to a magic protocol that doesn't exist; but that we should at
least consider making a wishlist of sorts of all the things that we
would want out of a "good" transport security protocol (if you have any
such ideas, please share them with me). I'll put up my crypto wishlist
sometime soon.
~aravk | ~nothien
---
Previous in thread (8 of 16): 🗣️ Phil Leblanc (philanc (a) gmail.com)
Next in thread (10 of 16): 🗣️ Phil Leblanc (philanc (a) gmail.com)