[tastroder]

Why wouldn't they? That group is trying to standardize a protocol that effectively negates a whole lot of progress and even tried to piggy back on the TLS name. Their stated requirements boil down to snake oil and laziness. If companies or groups thereof want to use security measures that aren't on par with the state of the art and intentionally ignore recent learnings, they of course still have that capability but I don't see why they should be given an opportunity to hide that fact behind a known bad standard. That'd only lead others to be forced to use a broken protocol for reasons like compliance.

[dogma1138]

Because companies in some sectors are required by law to inspect all traffic, while TLS 1.3 doesn’t prevent it in principle it makes it unfeasible to do so in practice given the number of sessions created in a large organization.

I work for such organization which actually took a fairly reasonable stance and told BOA to piss off when they asked us to join them in petitioning the IETF to make exemptions to PFS in TLS 1.3.

Our current stance is that we dissallow it internally until the vendors that provide us with the DPI and web traffic inspection solutions will have full scalable support for TLS 1.3 or until the regulation would change in a way that would no longer require us to capture, store and be able to decrypt all user traffic within the network.

[stefan_]

This was never about TLS. Only a stupid person would go "right, we have to decrypt traffic, we control the clients, lets break the crypto".

Surely your IT department already updates the software on client computers. Time to put on their big boy tech pants and decrypt data where the secrets are, on the clients. Then your industry can stop harassing everyone else for bad crypto.

[dogma1138]

Decrypting traffic on the client isn’t always possible due to how modern browsers operate.

Decrypting traffic on clients is also much harder due to the multiple types of clients you have and the fact that there is no easy way to MITM every connection the the client.

The security threat model by definition defines clients as untrustworthy hence relying on them for decryption is a flawed approach.

If you are going to be cocky and disrespectful at least be right.

[stefan_]

You control the client. There are companies making many many millions patching Excel to do fancier charts, I'm sure whatever vendor you got now desperately trying to steer the consortiums can instead figure out how to hook the crypto library in the one browser you install on clients.

Yeah, it's a hard problem. If you don't know half the things your clients are doing, it's much easier to pretend all the security conscious stuff will be going through TLS and then we break just that. It's also obviously wrong, as we all learned when they started filling USB ports with glue.

The boxes already rely on the client, unless someone signed another CA=yes certificate.

[dogma1138]

Again you do not trust your clients in this threat model because you can’t.

It’s simple a client makes an external TCP connection if that connection uses TLS the its MITMed on the network level and captured this happens to all connections if the client does not accept the handshake because for example the CA for the MITM box isn’t trusted or the client uses certificate pinning the client can simply refuse to proceed with the connection.

If the connection cannot be captured and inspected for any reason it’s simply terminated and the attempt is logged for future investigation.

There is no reason to break TLS on the client or compromise the browser it’s worse in every way and cannot be trusted.

[unparagoned]

If this was back in the days I'd everyone running ie maybe. But now they're is less control over clients and their browsers. Mitm is much easier, toy just install a certificate on the browser. Going client side means you need to change and modify every browser and piece of software with internet access. Or install some slow crappy firewall type thing and try and monitor things locally....

[tastroder]

Cool, doesn't really sound like we're disagreeing on the question "Why do people hate eTLS?" right? I sincerely hope regulation for your sector will change to reflect changing technical circumstances (though I realize how much of a long process that'd be). Your steps sound like a sane way to handle it, I get that you're currently forced to not use it and appreciate that you motion against weakening the protocol for the rest of the world. (Thanks for that btw.)

[peterwwillis]

> Their stated requirements boil down to snake oil and laziness.

Without knowing the internal structure of these particular organizations at all, that's quite a bold claim. If a company has a half million employees and their technology supports billions/trillions of dollars of transactions, it's quite likely that "laziness" has nothing to do with upgrading the entirety of the IPS & DLP products they support, to say nothing of solutions on the client or server side. They can't just edit some config and make all their technology magically support a new protocol that is explicitly designed to stymie their efforts.