patrickmcmanus

The IETF WG DBOUND tried to find a better solution to this problem and did not reach any consensus. fwiw.

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.

a 1 yen coin has a mass of 1 gram - which can be handy for measuring stuff.

absolutely! and some eTLDs are preloaded (like .dev) already and that of course applies to the domains registered in them - which is a nice property.

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.

I think we'll see some DNS version of alt-svc that doesn't require TCP to bootstrap.. see httpssvc and svcb

websockets is carried on TCP. Often bootrstapped on HTTPS tcp/443.

preamble of chunk length and 1 bit for end-of-message indicator.. if you only do chunk length you will eventually find you can't stream but want to.

or just use http.

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.

QUIC is considerably more resilient than TCP to RST attacks because it authenticates the transport itself once the handshake is complete.

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.

tl;dr; congestion control is basically pluggable.

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.

corollary question - if DNS data is not authenticated then how does the client distinguish between police and attackers?

much better to authenticate the policer.

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.

That was one of my favorite Mozilla Open Source Support projects!

restricted to: "solely to improve the performance of Cloudflare Resolver for Firefox and to assist us in debugging efforts if an issue arises"

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).

cdn switchers/sharers are very interesting here. e.g. cedexis

The most important attribute of DoH is, imo, authentication with the resolver. The browser has a terrible time with 3rd parties messing with the DNS stream. DoH allows the browser to be sure its using the resolver (and therefore the resolver policy) it intends to.

- The local DNS server deliberately does not resolve certain hosts (e.g. because it's running PiHole)

The right answer, imo, is that the pihole implements doh and firefox is configured to use it directly. The reoslver is authenticated and you're sure you're using the policy you want. A quick search indicates some interest in doing just that - I know stubby is working on doh support.

in the interim of course, you can just disable DoH and hope that your unauthenticated udp makes it to the pihole and back in tact :) - there's never going to be a lock in.

An internal host also happens to resolve on the external DNS, though with a different IP. E.g., a company could have its public DNS set to a catchall entry *.company.com, but at the same time could have dev.company.com set to a special IP

so far as we can tell, this doesn't seem to be a significant pattern with http content.. at least not to the point where both split horizon addresses correctly handshake from each side (defeating the fallback logic). I suspect this has to do with http caching not working very well in such a setup either. This is exactly what we're looking at error rates trying to determine, but the prevalence of other open resolvers like quad 8 seems to have really reduced the frequency of this kind of thing.

There are certainly some dev environments at the tail that will require manual config.. but for the most part those environments already have a bunch of manual config so this isn't a huge leap to do.

wrt esni the anonymity pool is definitely the set of content that can share the same address pool. In a world with lots of CDNS (and several multi-CDN switching services) this covers a huge amount of content - but I agree - not everything.

right - but we're coming for cleartext sni too:

https://tools.ietf.org/html/draft-rescorla-tls-esni-00

interestingly, something like DoH is a pre-requisite for pulling off esni.

The expected common deployment mode is soft fallback - using traditional DNS if connections cannot be made via the DoH resolved address. Captive portal provides the most common use case.

There is a hard failure mode available that you can use for better security if you're in a vanilla Internet environment - but we don't see a way to broadly offer that choice other than in technical documentation.

https://bitsup.blogspot.com/2018/05/the-benefits-of-https-fo...

not in hard-fail mode; but generally yes.

DoH on QUIC is probably the end result

Firefox has both soft-fail and hard-fail modes.. for a soft fail it will fallback to traditional port 53 DNS. Its likely that will be the most common deployment - you need it to deal with captive portals (i.e. the hotel wifi) and other split horizon issues as well cloud uptime incidents. But there is a hard fail mode if that is suitable for your environment.

or a positive privacy impact depending on where you live :)

we're coming after SNI too. One step at a time.

(also, 1] dns leaks are worse than sni leaks as typically more people are exposed to the dns query and 2] HTTP/2 can carry more than one hostname on a connection so some hostnames that appear in dns are never leaked through sni.)