Checks out. Google's development culture seems to live out the advice implied in Hyrum's law[1]. From Protocol Buffers intentionally changing JSON output field order[2], to Chrome randomly injecting an additional field in returned WebAuthn client data, to this. Seems pretty forward looking. If you don't GREASE where you want extensibility, you get rusty implementations.
This is a reaction is what you need to know, they weren't "forward looking".
TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3 all had problems where we've got an extension point in the prior standard, we just push this button and... now everything is on fire. Ugh.
So GREASE is for next time. When these same idiots ship their similarly incompetent garbage, the GREASE makes it not work. So the conversation goes like this:
Lazy Implementor: "Why doesn't my TLS 1.3 work?"
Anybody: "Did you read the standard?"
Lazy: "What do I look like? I've got a 16 digit IQ, of course I don't read standards"
Anybody: "That's your credit card number, not an IQ, and you should read the standard"
Lazy: "I think I know what an IQ is, and why should I read a stupid standard?"
Anybody: "Suit yourself if you don't want working TLS"
For TLS 1.3 here is what we had to resort to because these morons are "too clever" to read standards documents and do what we told them to do in TLS 1.2 so we had to invent a hack.
When your TLS 1.3 client calls a server it says effectively "I'm a TLS 1.2 client, here continuing our earlier conversation # BigRandomNumber. Do you remember that? Oh, by the way, I also know how to [Fly Casually This Is TLS 1.3; here are some magic numbers]"
A TLS 1.2 server has never seen BigRandomNumber before, and so it says sorry, we need to start from the beginning, and does so, speaking TLS 1.2 as if you'd connected. So that's compatible.
A TLS 1.3 server recognises this wheeze and replies in kind, "Hello TLS 1.2 client, I'm the server some.computer.example, we can continue our conversation, by the way I too know [Fly Casually This Is TLS 1.3; and here are my magic numbers]". And immediately after this, everything is encrypted, because they were both actually talking TLS 1.3 and they've got key agreement via exchanging magic numbers.
Idiot middle boxes, which would have freaked out if anybody admitted they were actually using TLS 1.3, despite clear instructions not to freak out when the future happens, think this is just a continuing conversation, they must have been power cycled since it started, or maybe a device came from another site, it doesn't matter, it says it's an ongoing conversation so it's fine...
Yeah, like everything else the moved to selling it as a separate (overpriced) dongle. This wasn't that bad, but now that they've removed the ethernet connectors also, you need both dongles connected in series, and you need to remove the Zerk-RJ45 adapter every time you plug the Ethernet cable, and it still doesn't help with your TLS connections over Wifi! I'm probably not the first to say it, but Apple's "Pro" line is clearly no longer aimed at professionals.
> David Benjamin, Google
Checks out. Google's development culture seems to live out the advice implied in Hyrum's law[1]. From Protocol Buffers intentionally changing JSON output field order[2], to Chrome randomly injecting an additional field in returned WebAuthn client data, to this. Seems pretty forward looking. If you don't GREASE where you want extensibility, you get rusty implementations.
[1] https://www.hyrumslaw.com [2] https://protobuf.dev/reference/go/faq/#unstable-json
This is a reaction is what you need to know, they weren't "forward looking".
TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3 all had problems where we've got an extension point in the prior standard, we just push this button and... now everything is on fire. Ugh.
So GREASE is for next time. When these same idiots ship their similarly incompetent garbage, the GREASE makes it not work. So the conversation goes like this:
Lazy Implementor: "Why doesn't my TLS 1.3 work?" Anybody: "Did you read the standard?" Lazy: "What do I look like? I've got a 16 digit IQ, of course I don't read standards" Anybody: "That's your credit card number, not an IQ, and you should read the standard" Lazy: "I think I know what an IQ is, and why should I read a stupid standard?" Anybody: "Suit yourself if you don't want working TLS"
For TLS 1.3 here is what we had to resort to because these morons are "too clever" to read standards documents and do what we told them to do in TLS 1.2 so we had to invent a hack.
When your TLS 1.3 client calls a server it says effectively "I'm a TLS 1.2 client, here continuing our earlier conversation # BigRandomNumber. Do you remember that? Oh, by the way, I also know how to [Fly Casually This Is TLS 1.3; here are some magic numbers]"
A TLS 1.2 server has never seen BigRandomNumber before, and so it says sorry, we need to start from the beginning, and does so, speaking TLS 1.2 as if you'd connected. So that's compatible.
A TLS 1.3 server recognises this wheeze and replies in kind, "Hello TLS 1.2 client, I'm the server some.computer.example, we can continue our conversation, by the way I too know [Fly Casually This Is TLS 1.3; and here are my magic numbers]". And immediately after this, everything is encrypted, because they were both actually talking TLS 1.3 and they've got key agreement via exchanging magic numbers.
Idiot middle boxes, which would have freaked out if anybody admitted they were actually using TLS 1.3, despite clear instructions not to freak out when the future happens, think this is just a continuing conversation, they must have been power cycled since it started, or maybe a device came from another site, it doesn't matter, it says it's an ongoing conversation so it's fine...
[Edited to fix various small things]
Perhaps in 40 years, we’ll still start encrypted sessions with TLS 1.2…
Hey, in 2024 we are still booting our 64bit PCs in 16bit real mode, just like the early 1980s! In the early 2000s, it was still crazy!
And we are still dealing with legacy PCI interrupt handling…
2 replies →
This became RFC 8701 in 2020: https://datatracker.ietf.org/doc/html/rfc8701
This was a lot easier before they removed the Zerk fitting from the Macbook.
Yeah, like everything else the moved to selling it as a separate (overpriced) dongle. This wasn't that bad, but now that they've removed the ethernet connectors also, you need both dongles connected in series, and you need to remove the Zerk-RJ45 adapter every time you plug the Ethernet cable, and it still doesn't help with your TLS connections over Wifi! I'm probably not the first to say it, but Apple's "Pro" line is clearly no longer aimed at professionals.