“snark bitterness side” I see so I’m not entitled to my feelings and I’m holding it wrong. No. It’s a disgrace. The latency is shit the precision is shit and WWVB to go with it is an insult.
Future proof? Are you living in the same future I am where our trades are front run? I notice you didn’t engage with the substance of my attack at all.
The paper https://www.blastradius.fail/pdf/radius.pdf) explicitly states DIAMETER "never replaced RADIUS for many common use cases" and "the protocol itself offers no security when used over TCP". So unless the DIAMETER traffic is isolated or tunneled, it's arguably less secure than RADIUS/TLS.
I work in telco, too - by my read, they're not disagreeing:
Although Diameter was intended to replace RADIUS, the
protocol itself offers no security when used over TCP. As a
result, RFC 6733 suggests that Diameter messages should
be secured using TLS or DTLS; 5G has replaced Diameter
with signaling over HTTP/2 [30].
"5G completely replaced DIAMETER with signaling over HTTP/2. DIAMETER is only used in legacy systems that has not yet been updated. Early 5G can be deployed as Non-standalone (NSA) or standalone (SA). NSA means a 4G core with 5G radio while SA means both 5G core and 5G radio. NSA has a lot of severe limitations. Many networks are already SA and the rest are working on rolling out SA."
Stock RSS feeds don’t work for future events, so they aren’t perfect for our usecase (warn users in advance of an upcoming date), so we offer ICS feeds instead.
RSS feed of just date changes might work, but ‘s hard to differentiate between a change that creates a feed notification vs one that doesn’t (new release, typo fix, date change by 2 days, and so on…)
"[PATCH] socks: return error if hostname too long for remote resolve
Prior to this change the state machine attempted to change the remote resolve to a local resolve if the hostname was longer than 255 characters. Unfortunately that did not work as intended and caused a security issue."
That's an entirely different threat model. hotpotamus is right - the article, and the threat model, are about offline attack of back-end password hashes, after they've been stolen or leaked. The speeds against fast hashes are indeed measured in the billions or trillions on ordinary commodity hardware.
Being able to firmly reject all unauthenticated messages is still the target end state. The risk of a threat actor sending an email that looks completely legit, and simply asking the user to "check their spam folder", is very real.
Site author here. Thanks for helping to get the word out - every bit may help someone.
While I consider my page to provide useful color, and I validate and summarize and cache info updates locally to add value ... it won't scale for long. It's really a stopgap - to buy defenders time until better efforts emerge.
A few efforts likely to become higher leverage than mine, because they can be driven by pull requests:
And far from a disgrace, NTP was a brilliant design for its time, and has proven to be far more future-proof than should have been expected.