Re: unsuitable protocols and standards that block innovation

[carlo von lynX]

Moin Martin,

On Tue, Mar 12, 2024 at 06:26:09AM +0000, Martin Schanzenbach wrote:
>  - Hiding in "common" Internet traffic: e.g. if two peers communicate
> via HTTPS (and assuming we can obfuscate the traffic patterns of the
> applications in GNUnet), they look like browser/web server to an
> attacker that may want to censor p2p traffic. The same holds for
> protocols such as SMTP* and XMPP. Some protocols (such as SMTP or XMPP)
> may come with significant overhead, but that is the price to pay to
> obfuscate the traffic.
> 
> *To be honest I am not sure how "useful" plain SMTP actually is,
> considering it is commonly run on top of a TLS connection anyway.
> I think anything running on top of TLS is sufficiently covered with an
> HTTPS or QUIC connector. Christian (who filed #1923) may have more
> insights on this.

I presume it is relevant that at some point we get to throw our
binary stream into the socket without completely obscene amounts
of overhead. That's how HTTP and SMTP can be sufficient because
you can say the next 100k of data are a binary file transfer.
XMPP cannot do that, so you would always have to encode GNUnet
streams into base64 or fake XML syntax, which is pretty nuts
and these days could get detected by AI.

You could at best use some STARTTLS negotiation of XMPP as an
excuse to switch to a TLS which then delivers GNUnet content,
but as you point out in your asterisk remark, the "usefulness"
depends on how frequent unencrypted XMPP still is, much like
unencrypted SMTP.

Consider that an observing entity can see the certificates and
pubkeys used in a TLS negotiation, so if we were to simulate
SMTP or XMPP we do not just need certificates signed by a credible
authority, they also need to have the respective bits set. Maybe
many XMPP sites actually do not care, but XMPP certificates were
supposed to have a specific XMPP flag set. So it may not be enough
to simply use a different port number.