Skip to main content


I've spoken about ossification many times and how that for example have prevented TFO (TCP Fast Open) to get deployed widely.

Today #wget2 joined the team disabled-TFO-by-default: lists.gnu.org/archive/html/bug…

in reply to daniel:// stenberg://

Do you have a talk or blog that I should read to learn more about your thoughts?
in reply to Jonathan Yu

@jawnsy in a recent HTTP/3 talk I did for example: youtube.com/live/d--aGkEPR3M?s…
in reply to daniel:// stenberg://

I mean pretty much the proof of ossification is everyone shoving everything over HTTPS/443 now. @joshbressers this smells like #osspodcast show material.
in reply to daniel:// stenberg://

@joshbressers That's something I think about a lot,. the default moving forwards seems to be everything has the security properties of always being encrypted (at rest, in transit, and someday in processing), and moving towards privacy preserving properties (like SNI needing to be replaced with ESNI) to the point of needing some padding/noise added in (like the token-length side-channel attack in AI, or timing keyboard strokes, or whatever). I guess the good news is that:

1) the overhead of crypto is way less of an issue thanks to hardware support (and we're getting better at all the key management and propagation bits)

and

2) the overhead of adding padding/noise is generally less of an issue since networks are steadily gaining bandwidth and lowering latency (like when I think of "bad" Internet now vs "GREAT" internet 25 years ago... yah. Not even close.).

in reply to kurtseifried (he/him)

@kurtseifried @joshbressers yes. Also of course we have learned over time to stop being so naive as we once were. Everything that is unencrypted gets abused sooner or later too easily.

But there's also a strong push against more and better crypto by powerful entities. For example, I think it will be interesting to see how/if ECH (formerly ESNI) will work in the wild due to how many large operators will cause problems.

in reply to daniel:// stenberg://

I don’t see how skipping the check if bidirectional communication is possible is a good thing? Routing paths are subject to change at any moment.
in reply to boiert

@boiert I am not involved in the change. You need to talk to the wget2 team.
in reply to daniel:// stenberg://

I made some comments on the RFC. However: The only use-case I found for this protocol would be an in-kernel advertising link-redirector.