> I'd figured that UNIX time just counts actual seconds
It doesn't. UNIX time is 1:1 with what your clock reads, you can convert between 2026-07-10 00:12:25 UTC and 1783642345 by simple math (note how the last digit is the same; but the leap second offset is 37s, that wouldn't align. The TAI timestamp for the same moment in time is 1783642382.)
> and that leap seconds and similar calendar shenanigans would be a problem of mapping epoch to the correct date, so that if normally epoch X maps to date D then both epoch X and X+1 map to date D.
It's the other way around, if you need to get the exact seconds between two UNIX timestamps (or calendar date/time), you need to check if there were any leap second changes between the two.
Counting actual seconds is TAI [https://en.wikipedia.org/wiki/International_Atomic_Time], that one is really just "number of Caesium hyperfine transitions since X", and now the mapping to a calendar date/time for display is a bit involved.
> I think for the stretch of time where a leap second is smeared, the epoch second would drift by a tiny fraction for each second or etc? So you'd have some chunk of UTC time where each second lasts something like 1.0005 epoch seconds, maybe?
Yes, 1.0000116s (or 0.9999884s), and to be clear it was never intended like that. It got started after a bunch of bugs in leap second handling caused issues & some people thought it would be better to just stretch/compress time for a period around leap seconds, for docs refer to e.g.: https://developers.google.com/time/smear
Personally speaking - it's a great way of just pushing the problem around, further complicating an already complex situation. 11.6µs is very measurable on a modern system.
> This would make converting from unix time to UTC need extra arbitrary handling for display, at least.
Except you need to know that leap smearing has been applied… which of course noone records. Most systems can't even signal it, much less store. If you need that level of precision, you better make sure none of your systems uses it or you're just screwed.
The really annoying part is that "leap smearing" (where people decided to just mush the leap second across about day) has made CLOCK_MONOTONIC unclear in this regard, since some leap smearing approaches affect that as well. Which destroyed any assumption a developer could make about CLOCK_MONOTONIC, since you won't know if leap smearing is in use :(.
(And depending on the leap smearing implementation, it also smears CLOCK_TAI, jumps it to opposite polarity at the actual time of leap second, and then smears it again. The leap smearing people really made a mess of this.)
From a correctness perspective, the only good choice is to go all-in on TAI.
[Ed./P.S.:] "just ignore leap seconds" - that's going all-in on TAI. At this point it's probably easier to redefine UNIX timestamps as TAI based after 2035 ("abolishing leap seconds"), and introduce a new CLOCK_SOLAR_EARTH that accumulates leap seconds and can be used if/where necessary. The main issue is to create a proper delineation between the two clocks, which we just don't have at this point. Way too many systems where it's just not clear what they use.
And note that leap seconds are earth specific too. You'll have entirely different requirements on e.g. Mars.
UNIX timestamps are fully ignorant of leap seconds, i.e. pretends they don't exist. That means there can be physical seconds of time that cannot be referenced with a UNIX timestamp (when a leap second is inserted) as well as UNIX timestamps for seconds that don't exist (when a leap second is deleted).
Curious. Most places needing SSO also have legal retention requirements, making E2E a hard nonstarter. And most E2E users wouldn't want to rely on a SSO that could likely revoke their keys. What's your environment?
What I said was "It makes much more sense to argue there is no consensus […] can be argued even in a "60:40" situation regardless of direction".
Not "there's a 60/40 split, therefore there's no consensus".
Can be argued even in. That's a statement of allowance, not sufficiency. And I was speaking in the context of contrasting against a vote. You can't argue with a vote's tally.
Anyone know if "-cpu ${CPU},vmx=off,svm=off" in QEMU is a safe workaround for this?
(To disable nested virtualization on a per-VM basis. Only against exploitation from within that specific VM, obviously does nothing against users with access to /dev/kvm on the host.)
> A single sentence of encouragement is all that is on offer from this MLKEM RFC.
The draft only specifies the MLKEM binding into TLS; it'd be out of scope for it to go into detail on implementation considerations for MLKEM. Those would belong in or adjacent to FIPS 203 (the actual MLKEM specification).
> It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]
It's actually RFC8032 that this criticism would apply to, since it is actually specifying EdDSA, not just referencing it externally.
* the IETF's approach predates 15 U.S.C. §4302 by more than a decade
* every single case example cited is US-American scoped¹ SDOs: American Society of Mechanical Engineers, National Fire Protection Association, American
National Standards Institute²
¹ NB scope ≠ legal domicile. The IETF's legal status is… complicated… but does have US dependencies. Its scope is world-wide though. Not so for any of the mentioned entities, even if…
² …ANSI is a borderline case since it is the constituent ISO member. But still, it's the US entity.
I'm not trying to make a legal argument here, but… I'll say he shouldn't be trying to do that either. Most mathematicians and CS majors make very poor lawyers in any case, and often enough without any awareness of it.
> I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an opponent of all security and (especially) cryptographic standards bodies.
Hmm. This doesn't entirely connect for me… WireGuard and OpenSSH are first and foremost implementations. Are you implying people should follow a "primary" implementation? Does WireGuard even have a protocol specification? (searches - ah, yes, it does. I do know there have been a very number of "further" implementations [e.g. on FreeBSD], though I'm not sure if they're derivative or clean-room.)
But then isn't this just replacing IETF processes with whatever community or corporate processes those projects have? Wouldn't that just be "get shit into {the Linux kernel,OpenBSD}"? They've gotten better but both of those communities have their shortcomings. (For Linux, it's not the social interactions anymore, at this point it's the significant corporate interests.)
Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.
Informational RFCs still need to pass through the IETF consensus process, changing the intended status isn't a procedural bypass. However, the authors can just publish it elsewhere, it makes no difference at all for the codepoint allocations. Only distinction is that it doesn't get the somewhat intangible (but existent) "RFC sheen".
> whether he realizes it or not, he's operating in supremely bad faith this time.
I've met him in person, once, at a CCC event about a decade ago, and as someone clueless about cryptography all I can say to that is that he certainly had (has?) a my-way-or-the-highway personality.
> I, too, don't support the IETF
Out of curiosity, how would you maintain e.g. TLS? Something more academic? Raw "throw it all out there, best-wins"? Another SDO (e.g. ITU)? Other more formal international processes?
I do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.
That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.
From the way DJB talks about IETF processes, it's quite clear to me though that he has little trust/belief in the IETF consensus process. I thought he said as much somewhere but can't find that right now. (It's particularly obvious in https://blog.cr.yp.to/20260405-votes.html)
Which is why I'm noting the alienation of "IETF believers", which I should maybe clarify I count myself as. The IETF is a lot of people doing a lot of good work. It does include a bunch of questionable actors, anything from ignorant, incompetent, ulterior motives, to outright malicious. But all in all it has brought us the internet as it exists today and I can't help feeling a little, well, alienated by DJB's writs.
Anyway, IETF hasn't attempted to issue such a rule. On the contrary, IETF claims that WG decisions are not taken by voting: "Decisions within WGs, as with the broader IETF, are taken by 'rough consensus' and not by voting." This begs the question of what IETF thinks "rough consensus" means. Letting chairs make arbitrary decisions is a violation of due process.
More to the point, IETF can't override the definition of "consensus" in the law. That definition requires general agreement. Adoption of this draft was controversial, and didn't reach general agreement.
DJB making legal-ish arguments (or the idea that the IETF could be sued over a definition of "rough consensus") is absolutely inane to me. The choice of words of the IETF in defining its own processes for itself is not a legal one. And apart from that, which country's laws would that be? (I'm also quite skeptical about such a definition existing in a relevant manner to begin with.)
Actually… what would even be the result of the pure MLKEM document getting dropped by the IETF? I guess the entries would temporarily be marked deprecated or something, until another reference is made available somewhere, describing the same behavior? I'm not sure what procedural blockers this might run into but my general sense is that the IETF & IANA wouldn't "block off" the already allocated codepoints from being specified elsewhere (or allocate new duplicate codepoints) so long as the behavior is identical.
> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.
The IETF document only documents how and where to put the MLKEM values into TLS. MLKEM itself is specified in FIPS203 and it just references that for the actual cryptographic details. The IETF document is in fact quite short:
https://chaos.social/@equinox