peanut-walrus

MPTCP uses TCP options fields, the vulnerability is in IP options.

Some notes I've got about this:

- MPTCP is not a requirement, it is a generic use-after-free.

- Exploitability over the internet is unlikely, most ISP routers drop packets with IP options fields.

- At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation.

- Successful exploit requires multiple CPU cores to process packets, so systems with just a single core or packet processing pinned to a single core are not affected.

> also, doesn't DNSSEC prevent this anyway?

As per usual, the answer is no. DNSSEC prevents resolver cache poisoning for trusted resolvers which validate DNSSEC. That is literally it. It provides no security against the vast majority of attacks against DNS.

Also limited protection against MitM upstream of the resolver, spoofing is prevented but denial of service is still possible.

The typical scenario for majority of users unfortunately does not include a password manager, passkeys are a huge step up from that.

For the people already using password managers, it's not a huge step to get a Yubikey and use that for hardware-backed passkeys.

Absolutely not. Phishing resistance is the big one. But also if hardware backed, resistant to stealers.

I've been using my own domain with a catchall for over 10 years and never had problems with spam. Spammers tend to send to harvested address lists, not just try to send to random mailboxes for a domain.

IP and Ethernet were developed around the same time and also became the dominant standards around the same time. But they were mostly unrelated, so you had token ring networks running TCP/IP and Ethernet networks running IPX and all sorts of other combinations. So it's not quite as simple as that. I don't think there's ever been a time when there was a significant adoption of Ethernet without using it in combination with some L3 protocol.

Quite common to run unnumbered IS-IS backbones. Whether this can rightfully be considered a "LAN" is up for debate.

Transparency logs. It's mandatory for a cert to be in CT logs for browsers to trust it. Those are public, if this was happening, someone would have noticed already.

There is no such thing as unfixable. It's just kicking the can down the road. Look at how email devolved because of the features that made spam "unfixable". I would like dns not to go down the same path, which seems all too likely if nothing is done. Already most corporate networks are blocking most "new" domains. It's only a matter of time before new domains you buy are essentially unusable.

> The rational soul can be made only by creation.

From Aquinas' Summa Theologiae. The argument this article presents does seem very similar. Weirdly, the article itself is very dismissive of religion, while making a similar argument to the one Aquinas made 750 years ago.

Because web security has a lot of legacy crap. Such as cookies. Oh you added Domain=foo.com to your cookie? Now marketingvibecodedapp.foo.com can access the cookie from your main domain. What do you mean you thought adding the domain field restricts the cookie to just that domain? Lol no, it's the exact opposite, gotcha, dumbass.

In theory, yes, in practice this will currently result in deliverability issues, both for servers which don't speak dmarc and for spam signals. I have tried this :)

If this mode of operation was an explicit choice, this would give me the option to have a fallback SPF record for legacy mail systems, but most up-to-date servers will use the more secure and (for my use case) operationally simpler verification.

Missed opportunity to get rid of SPF. What I want to my DMARC policy to say: if someone is sending you an email that claims to be from my domain and it's not signed by one of the keys I have published under my domain, you should reject it, regardless where it came from.

And on the receiving side, the policy is similarly simple: if I receive any unsigned or unaligned email, I will reject it.

Edit: to clarify, I want there to be an option where I specify my DMARC policy to explicitly tell well-configured receiving servers "ignore whatever I have configured as my SPF record, only look at the signatures". There will no doubt be a long tail of mail servers where I will still need an SPF record for them to accept my mail.

Edit2: Another feature that I feel is lacking is ability to give dkim selectors a scope - e.g. this key is only valid for these particular From addresses.

Turns out you don't actually need top-tier engineering talent if your only business is selling ads to scammers to prey on the elderly?