GKE can't offer financial backed SLOs without charging for the service. This is something that, I assume, significant customers want and that competitors already have:
HMACs do not require collision resistance from the underlying hash to provide secure message authentication. HMAC-MD5 is still considered "secure", although that doesn't mean you should use it.
For connecting VMs without public IPs to the outside world, Cloud NAT is the easiest answer. You could set one up yourself if you were so inclined (e.g. some forwarding rules and iptables rules on the bastion).
For ssh key distribution, there's a few options. You can store the key in Secret Manager and run your GCE VMs as a service account that has access to the key, then fetch it when pulling.
An ecosystem has evolved around Borg. Custom hardware, kernel, schedulers, telemetry, atomic clocks, networking, security, management... have all evolved around Borg proper to meet the "enterprise" needs of one of the largest enterprises in the world. It has many niche (i.e. not generally useful) cababilites built to service hardware melting XXX megawatt applications like web indexing, gmail, colossus. Even if Kubernetes targeted this customer, Borg has a significant head start. At this point the Borg ecosystem is almost old enough to by cigarettes in Mountain View.
A zero-day is an interesting label to put on a bug disclosed "after the company failed to fix the issue within 90 days". I guess, you learn something new every zero-day.
* They know when they can serve 0RTT from their cache safely because they can be reasonably certain if handling a cached request is side effect free.
* If connections to backend origins are reasonably persistent, there's not much latency reduction benefit from 0RTT compared to connections from consumer user agents.
Use go for what? DNS resolution? The default behavior is to use the system DNS resolver. The Go resolver will be used if the system is resolver is not avaialble (e.g. if the binary is compiled as pure go) or if the net.Resolver has the PreferGo flag set (which is false by default).
By default, go compiles binaries linked to libc to use the system DNS resolver. It does re-implement a DNS resolver but it's only used if CGO is disabled at compilation time.
It’s pretty unweildy compared to HMAC construction because:
* each caveat addition requires local generation of a new asymmetric key pair
* the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID.
* it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender.
It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.
The published asymmetric macaroon constructions were pretty gross last time I looked. We were missing a practical asymmetrically verifiable append only signature. This deficiency rules macaroons out of numerous use cases (namely where the relying party is separate from and untrusted by the issuing party).
Token binding changed a few things as it evolved from origin bound certificates, notably:
* moving from using client certs to signing exported keying material[0] to prove key possession
* adding support for RSA keys
* adding support for multiple token bindings on a single connection (see referred token binding)
Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.
> In neither case do I anticipate widespread use
For the browser case:
* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).
* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to
slow to be used practically.
* Many compromises happen in the browser so token binding only marginally improves the security of cookies.
I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.
A couple corrections to the section on token binding:
1. It works on all TLS connections, not just mTLS connections. It even works on unauthenticated TLS (although I wouldn't advise forgoing server authentication). That's the beauty of key binding the token. It's useless without the key.
2. It's unclear what the tokbind noun refers to in this paragraph. I'm going to assume that you are just referring to the token binding. A token binding lasts for the duration of a TLS connection (sans renegotiation and resumption which complicate things) and is derived from the [clientrandom,serverrandom,mastersecret] of the connection. The token binding secret is just an RSA or ECDSA keypair, independent of client or server certificates, that is generated when the token is issued. The token is bound to the keypair (e.g. by a hash of the public key that's stored in a JWT claim or stored in a database table keyed by an opaque oauth token).
3. Anyone can use token binding, not just members of the IETF TLS working group :)
You can map ingress/egress channels of a network device directly into a processes memory inuserspace. These are just memory pages in what's known as the DMA region that the device can write to without interacting with the CPU.
> Package ptrace provides a ptrace-based implementation of the platform interface. This is useful for development and testing purposes primarily, and runs on stock kernels without special permissions.