The current way most of this is handled is via a list published at
publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"),
and the general goal is to accommodate anything people are
using that for today. However, there are broadly speaking two use
patterns. The first is a "top ancestor organization" case. In this case,
the goal is to find a single superordinate name in the DNS tree that can
properly make assertions about the policies and procedures of
subordinate names. The second is to determine, given two different
names, whether they are governed by the same administrative authority.
The goal of the DBOUND working group is to develop a unified solution,
if possible, for determining organizational domain boundaries. However,
the working group may discover that the use cases require different
solutions. Should that happen, the working group will develop those
different solutions, using as many common pieces as it can.
you're thinking of an exploit in spdy (the h2 predecessor) in which the headers were just run through the same gzip context. The HPACK format in h2 and h3 is meant to remove those oracles. (though it is less effective bytewise than gzip).
protecting against the zero-bound is the value - that's not a scam. As the ratio of potential loss to net worth drops, that's less interesting and so is the insurance.
Varying levels of deductible choices hard code this notion even further into the system. If you're farther from zero-bound worries you can essentially buy less insurance with a high deductible.
the author is writing, in that section, about blind (i.e. off path) attacks. Given the attacker in that model is off-path they don't see the challenge ack.
The way I look at it a lot of what we logically think of as the network layer often exists in userspace anyhow. That's the point of DPDK/snabb/netmap and other kinds of driver bypass.
The important design distinction about the layers is what element has access to what data. (e.g. routers need to see IP addresses to do their job, port numbers help kernels segment permission models, etc..) The rest of it is just about logical models, real-world workarounds, and luck...
HTTP/3 will be able to get high bandwidth, buttery responsive restarts to connections far too long idle to keep "open" because it integrates security, application, and transport. That's thoughtful design, not a workaround.
I'm going to paraphrase (and maybe bungle, because I don't have it at hand) from my favorite networking book of all time - the underappreciated _Network Algorithmics_ by George Varghese. He describes layers as a lovely way to model and think about a protocol or design, but often a terrible way to build one. I've spent a lot of time thinking about that, and I think QUIC gets it right - the layers are clear in how they inter-relate but they do so without being independent.
Much like in TCP, congestion control really isnt something required for interoperation between peers. Given the userspace nature of QUIC I would expect to see a lot of iteration on this front - for good and bad. (but hopefully the bad iterates quickly).
The current drafts describe newreno is detail, but also explicitly call out the ability to run other things. I've seen reno, cubic, and bbr all run with quic and anticipate others to happen as well. That's one of the exciting things here.
These are essentially seperable features - and given that QUIC is at a later stage than ESNI there is not a compelling reason to create a blocker to getting an open QUIC standardized.
QUIC uses the TLS 1.3 client hello (and its extension mechanism) for the handshake, so evolutions to TLS 1.3 like ESNI will be automatically valid in QUIC too as they come down the pike.
as they say - there are many reasons a company can succeed, but they all fail for the same reason. (they run out of money).
So cash is king - follow the signs of cash flow.
#1 - watch the sales staff. Their comp is a direct reflection of the company's cash flow. They will leave if the source is running dry and they don't need inside information to figure it out.
#2 - hiring freeze. Classic bad sign. This is a little different than reaching hiring targets - if there is no backfill for attrition though, its a flashing red light.
#3 - travel freeze. Often the first lever pulled by the operations team - its a tell there are cash problems.
C level shakeups are not great indicators. Could be a real problem, but it could also just be powerplay fallout.
the post is good.. but also: confidentiality matters.
Think about a library. There are no secrets in the stacks that need to be kept from public disclosure. What is secret is the act of using the library - i.e. what they choose to read.
The counterpoint is that traditional DNS has horrendous loss recovery and basically no congestion control and these things definitely benefit DoH at the tail.
QUIC will let us have it both ways (and as QUIC has an HTTP definition, its basically a free upgrade for DoH).
https://datatracker.ietf.org/wg/dbound/about/
The current way most of this is handled is via a list published at publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"), and the general goal is to accommodate anything people are using that for today. However, there are broadly speaking two use patterns. The first is a "top ancestor organization" case. In this case, the goal is to find a single superordinate name in the DNS tree that can properly make assertions about the policies and procedures of subordinate names. The second is to determine, given two different names, whether they are governed by the same administrative authority. The goal of the DBOUND working group is to develop a unified solution, if possible, for determining organizational domain boundaries. However, the working group may discover that the use cases require different solutions. Should that happen, the working group will develop those different solutions, using as many common pieces as it can.