So, while average request may have to travel quarter (not half) of the Internet globe, median request from the set of requests that matter has much lower latency.

Barcelona to Stockholm is about 65ms, ~35ms to Amsterdam, ~43ms to Frankfurt.

HTTP/3 is ubiquitous, you don’t get TCP handshake penalty anymore in major browsers.

If all your users are in Spain and you don’t care how fast your site loads for a techbro in California, you indeed don’t need CDN.

You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.

Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.

First, long-living credentials are the standard because the machinery to rotate them is complicated and, in fact, via indirection requires another set of long-living credentials. Out of all problems that any security engineering team has to solve at an organisation, this one stands high on the cost of implementation, adds friction to everyone involved including end-users, and is low on the value provided (compare to, say, network segmentation).

Second, while proclaiming no long-living credentials, they, in fact argue for concentration of long living credentials in running software that will be the target of intrusion. They say, the options are “a vault that only issues short-lived creds based on long-lived creds that you insert once and that it never gives back” and “a credential-injecting proxy”. Both of those applications hold long-living credentials in memory. Recall, the attacker had root privileges on the node, so dumping the creds from the memory with a little disassembly if needed, was in reach of the AI agent.

Funny enough, they dismiss the working solution: “we had to turn TPM storage off by default on Linux and Windows” - because they could not figure out how to work with TPM? Resealing and the workings of configuration registers is non-trivial, I admit, but totally manageable.

To sum up, I feel the author bends backwards to preach for the religion of short-living credentials even when they are not a solution while providing contradictory arguments for their case. This is why I called it bs.

Local data access is a win, I agree

There are no performance implications of using a proper 128 key because they are doing AES anyway. If they were resource constrained and choose a variant of TEA encryption due to constraints, it would be understandable, but no, the encryption is implemented in hardware.

There also seems there is no message authentication, a rookie mistake.

SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.

Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.

1. Weather reports that were encrypted with Enigma for the High Command and then sent again encrypted with a much weaker cipher for (if I recall correctly) merchant fleet.

2. “Keine besondere Nachrichten” or “Keine besondere Ereignesse” - depending on sources. It means “no important news” or “no important events”.

3. “Heil Hitler” at the end of the message. This one is maybe an anecdote. If something like that would be sent I suspect the radio operators would send “HH” at most.

Then, Chrome got an update and started hijacking the enrolment process from the operating system and created keys synced to Google Account. This resulted worse UX because authentication now required pulling the Android phone (for those unlucky ones who have it) and confirming the login there instead of doing it right on the computer, uninterrupted.

Then, Apple followed with cloud-only key pairs and then so did the password managers (including Bitwarden Enterprise we were using) and everything become a mess.

The only solution would be to use the key attestation and to only allow specific security keys. Both Chrome and Apple have config knobs to simplify enterprise attestation (a strong assurance, which FIDO authenticator has been used), but neither Windows nor macOS support key attestation for hardware-backed keys (and macOS ignores “platform” claim altogether).

It sucks.

This

    > Which is happening with all the big platforms right now.

Consider:

1. Password managers tie passwords to sites, so phishing-resistance is achieved. 2. Password managers allow long, complicated, individual password per web site, so compromise blast radius is 1.

In non-resident keys scenario you don’t store anything and from what I see there is no security downside of using non-resident keys.

Loosing both (or multiple) security keys is like loosing all your car or home keys. Very inconvenient, agreed.

Anyway, I think we can agree that FIDO authentication protocol implementation is a mess. Apple and Google made it messy because they wanted to lock down users to their platforms and then password managers followed. As a result, the current implementation is not more secure than “login with Apple” or “login with Google”.

From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.

Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.

It was not. The original U2F spec was created before that idea was around and it talked about hardware security keys as means to store the primary key pair.