Gemini privacy

[nothien at uber.space]

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