Yeah cert pinning is annoying but there's competing interests over that. The application vendors don't want you to be able to inspect the data & generally that's true as well. The niche debugging/analysis use-case can still typically be managed by disabling cert pinning once you have root (unless the application has its own TLS implementation which gets trickier).

re mac address == strong link level identity, it was never that and using it in that sense isn't accomplishing much. MAC addresses are trivial to spoof. If you want identity, then use proper cryptographic mechanisms to establish that (e.g. mTLS).

What we've seen as a profession is that that level of flexibility makes things harder to configure correctly leading to various security vulnerabilities. Or the optionality being user facing makes it not user friendly and makes it easy to socially engineer attacks. It sucks but in practice we've not found a way to optimize along several axes simultaneously. Don't forget that all your optional features is stuff someone has to build, implement, test & maintain. The only way out I think is to demonstrate a way forward that manages to attain the goals you seek without sacrificing the technical privacy measure. The technical privacy measures have been put in place as a result of real-world lessons learned, not hypothetical things.

> Re configurable TLS: TLS 1.3 allows services to perfectly pin certs and reject your custom root CA. It breaks the flow you are talking about that has worked up to 1.2. The answer is to not build a myopic protocol/technology that only cares about 1 dimension of usage.

No it doesn't. I have no idea what technology you think this is (maybe HPKP?), but installing a local root CA absolutely continues to work in all browsers with TLS 1.3.

TLS proxies need to be able to inspect the server certificate response in order to dynamically generate an appropriate certificate. This flow doesn't work in TLS 1.3 since the certificate is encrypted to prevent MITM.

MITM for TLSv1.3 is possible. Plenty of solutions available for enterprises to do this. The MITM occurs still happens for TLSv1.3 on key exchange, allowing for the subsequent certificate to also be MITM and be replaced and encrypted. The only real affect TLSv1.3 has for MITM is that company policies for decryption can't match on the cert to determine if decrypt should occur, but they can still use the SNI which is plaintext

I thought combined with encrypted SNI this was no longer possible since the middleware doesn't have access to that information.