[lexman0]

There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business.

Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users".

The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt it.

Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted. This would be worse than copying the TLS1.2 traffic for out-of-band scanning.

I'm not saying that this guy wasn't a little late by the party, but failing to recognise that big businesses have regulations you don't understand or even care about is a huge mistake that will make us all more insecure. After all, who doesn't have a bank account?

[tremon]

I would have preferred if HN linked to this response, as it is much more in-depth: https://www.ietf.org/mail-archive/web/tls/current/msg21325.h...

Endpoint security is paramount, and some sort of network MitM system is absolutely not a replacement for endpoint agents. I would highly suggest deploying agents on your endpoints.

If you're relying on MitMing S2S traffic for debugging a payment stack, it sounds like your payment stack is opaque to you, which is not only a concern for security, but the general reliable operation of your payment stack as a whole.

[qznc]

The original request (see TFA) already addresses this:

> End point monitoring: This technique does not replace the pervasive network visibility that private enterprises will lose without the RSA key exchange. Ensuring that every endpoint has a monitoring agent installed and functioning at all times is vastly more complex than ensuring that a network traffic inspection appliance is present and functioning. In the case of monitoring of supervised employee communications, moving the monitoring function to the endpoint raises new security concerns focusing on deliberate circumvention - because in the supervision use case the threat vector is the possessor of the endpoint.

[userbinator]

Taking this further, let's not forget the fact that some endpoints might not even be capable of hosting a "monitoring agent", or it be unfeasible to develop and install one on every single endpoint. Admittedly not directly related to financial institutions, but all the IoT stuff comes to mind as something even consumers would want visibility into the traffic of...

In fact, those endpoints themselves might be locked-down environments secured against monitoring... ironically by the same "secure everything against everything else" attitude.

[zrm]

> Ensuring that every endpoint has a monitoring agent installed and functioning at all times is vastly more complex than ensuring that a network traffic inspection appliance is present and functioning.

That complexity is a sunk cost. You can't guarantee that the network path through the inspection device is the only one available in a world of cellular data and tethering, twelve different kinds of VPN service some of which can purposely look like HTTP, file-level encryption etc.

> In the case of monitoring of supervised employee communications, moving the monitoring function to the endpoint raises new security concerns focusing on deliberate circumvention - because in the supervision use case the threat vector is the possessor of the endpoint.

If the user is the threat then everything on their endpoint is already compromised. Preventing external communication would then require prohibiting every mobile device capable of tethering, constant body cavity searches for storage devices or wireless hardware, etc. If you need that level of security then your internal network should not be connected to the internet at all.

And if you have internal threats but can't justify those measures then it's all the more important that everything is secured at the endpoints to protect the other endpoints from the adversary on the internal side of the inspection device.

[drvdevd]

Wow that is right in line with my own response and does change the conversation. Thank you.

[raesene6]

With regards to your example, in my experience in the banking industry, you just re-encrypt for the internal leg.

TBH I think the BITS guy is over-egging his case a fair bit.

For all outbound to Internet comms they've got to use an interecepting proxy anyway 'cause they're unlikely to have the relevant private key for the communication. So those systems are in place already.

For inbound comms sure there's a hit, you'd need to decrypt at the time of interception and then re-encrypt with a key you know to avoid storing the data in plaintext, but it's far from impossible. And given that the timeline for deprecation of TLS 1.2 is a loong way off, they've got a load of warning to ensure that they can work around it.

[blazespin]

Yeah, but this means you end up with all this communication infrastructure with MITM or DMZ termination of ssl. Is that really going to be more secure than just allowing for non forward secrecy? Just because the working group removes non forward secrecy from tls doesn't mean it's going to make things better.

[raesene6]

Well part of my point was they already have MITM infrastructure and DMZ termination of SSL is something I've seen many times in banks, so it's not exactly an unknown concept there.

As to your question of whether it's more secure, I'd ask more secure for whom? It's obvious that forward secrecy provides valuable additional protection for ordinary users of TLS. That financial services organisations will need to account for a different method of achieving the same goals they have now at some hypothetical point in the future when TLSv1.2 is deprecated, doesn't seem an unreasonable trade-off to me, but then I don't have to pay for those new systems.

As I said in my original comment I think the BITS guy is over-blowing his arguments to make a point.

[TheBobinator]

Implementing an official Bump-in-the-wire MITM method for TLS would be the final nail in the coffin of the protocol; nobody would take it seriously and would move onto IPSEC.

If big business needs to secure communications in and out of the enterprise, then they need to stop being lazy about it. Tap the endpoints and use internet proxies, block communications with unapproved websites, and install surveillance gear in the conference rooms. I get these are costly measures, but they are only costly because of input cost to get there, not operating cost.

Want to know how you get a gargantuan database out of any company? Ship it out the firewall through a client PC as a H.323 video stream through your favorite software package. You tell me how to filter that one on a modern, carrier grade Pal-Alto firewall? We have tremendous holes in the existing infrastructure because we don't want to put the work into actual security or into fundamental theory.

The bias here is the market should slow down for big business, the reality is, big business not being on the ball and putting pressure for changes on a protocol like this is a tremendous subsidy to those companies. Frankly, public sediment is right in this case, the big businesses should bare the brunt and cost of their mistakes.

[cmdrfred]

I agree, this isn't a low margin business either. We are talking about inferior security for all internet users for the sake of Well Fargo's quarterly report.

[cryptarch]

I really like "public sediment"!

Thank you for the eggcorn.

[uola]

> [...] nobody would take it seriously and would move onto IPSEC.

Sounds good to me.

[lazyjones]

> Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted.

Sorry, I don't get it. All encrypted traffic is typically decrypted by the recipient. There's no need to add transport-level vulnerabilities to facilitate virus/exploit checks.

[superuser2]

>All encrypted traffic is typically decrypted by the recipient.

The use-cases for inspection at the corporate firewall are often explicitly about catching cases where the recipient isn't policing itself:

- the device is compromised, exfiltrating company secrets, but has been rigged to send false reports to the central antivirus server saying it's clean.

- the device is not something it makes sense to install a host-based IDS/firewall/AV on.

- the device is assigned to a broker-dealer who is using a non-work email account to give fraudulent advice to clients off the record.

In an enterprise IT environment, "the recipient" is the company, and the company has internal controls, often required by law or regulation, that involve i.e. people who are not salesmen or traders (IT, compliance, legal, etc) knowing what information flows into and out of the sales and trading departments.

[lazyjones]

>- the device is compromised, exfiltrating company secrets, but has been rigged to send false reports to the central antivirus server saying it's clean. - the device is not something it makes sense to install a host-based IDS/firewall/AV on. - the device is assigned to a broker-dealer who is using a non-work email account to give fraudulent advice to clients off the record.

So, because banks fail at keeping their devices secure, TLS 1.3 must be weakened? I don't see a convincing case here.

The third point especially seems a bit ridiculous: non-work accounts can probably be used from anywhere, why would said broker-dealer bother using the bank's network for his fraudulent activities? If he controls his device, he can use an LTE USB stick, an external VPN with a cipher of his choice etc. ...

[tremon]

The use-cases for inspection at the corporate firewall are often explicitly about catching cases where the recipient isn't policing itself

But I don't want financial institutions to use clients that can't be trusted to police themselves.

[Lazare]

Yeah? Neither do they.

[blazespin]

The guy is basically complaining that they have to change all their infra over to MITM versus just decrypting traffic with private keys.

He is right, it will be expensive. And he has a right to complain. Should the working group ignore him? It's a tough call. You risk forking standards when you start to do that.

[drvdevd]

I think the working group should ignore him because he ultimately wants to save a buck now and shoot himself in the foot, he just doesn't realize it yet.

The enterprise as walled garden approach to security seems quite out of date and is harmful to all parties involved. Like it or not, the Internet at large has made our life one big WAN party, and we need to come to terms with that sooner rather than later.

[xg15]

That clashes big time with the fact that more users than ever are online today with no clue at all about security. (And it's not practical to change that)

So how would that new approach look? The de-facto solution today is that security is more and more delegated to device vendors and cloud providers. But that seems worse to me than delegating it to the admins of your organization that you know and trust.

[drvdevd]

I don't think it's so much about who you delegate responsibiltiy for securing networks to so much as how that security actually works. I believe traditional perimeter security is dead or dying and the idea of incident responders manually pouring over pcap files just doesn't scale much further either.

We need machines and global policy to help do this work and we need to stop putting faith in magic black boxes which we know will be thoroughly compromised (e.g.: all enterprise vendor equipment).

More on point, TLS 1.3 seems like a step in the right direction of thought: that you can improve your local security posture by improving the global posture.

[ChoHag]

The problem he has is that while we're obviating the need for a wall, we're also denying even the possibility of an attractive ironwork fence.

[ivan_gammel]

It will be expensive, but there's a big market for that. I'm pretty sure that the costs will fall, as soon as the industry understands the demand.

[dimman]

Most likely yes, the only sad part is that as soon as there's a cost for banks, it's the customers who ends up paying for them one way or another.

[Yaa101]

Which is not the worst outcome since customers too will benefit from the security...

[pdpi]

All encrypted traffic is decrypted by the recipient, sure. Who's "the recipient" though? Do all your services handle tls, or do you terminate tls at an haproxy/Nginx/etc before hitting the actual services? How many hops do the unencrypted payloads take inside your network? Do you agree that it would be best to reduce that number to a minimum? There's ways to work around this, but they have trade offs associated with them, and they do have a reasonable requirement here.

[userbinator]

If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key...

I agree that his message was a rational argument. The dismissive response was disappointing, however.

Ultimately, the conflict of interest here is created by the fact that not everyone wants the same set of security properties. (Rhetorical question: does everyone want DRM? It's "more secure"!) The important thing to keep in mind whenever reading about security is what it secures against. It is not unreasonable that banks want to audit the data that flows through their network, in the same way that I should also have a right to inspect the data my devices are communicating on my network. The example I like to remember is the smart TV that phones home with viewing info --- discovered because it was doing it in plaintext.

Rationale: We're trying to build a more secure internet.

Phrases like this rather bother me because it assumes everyone wants the same security properties, which is clearly not the case given this example. "more secure" against what? "secure everything against everything else" seems like a popular attitude recently, and I think it does more harm than good.

Relatedly, it's already hard enough with many "smart devices" that aren't full PCs to add your own CA and do MITM; I can't imagine logging session keys to be any easier if even feasible.

I'm with the banks on this one.

[raesene6]

I would agree that not everyone wants the same set of security problems and that this causes the conflict evident in the mailing thread, not so sure I'm completely with the banks on this one though.

Standards bodies are trying to improve security for a very wide range of people and the obvious target with this is that they're trying to mitigate the risk that government agencies and others can passively read encrypted traffic and then demand access to the server's keys to decrypt.

This is a very real risk, and one with security benefits to mitigating.

Now obviously banks (and other corps) have a legitimate need to intercept and decrypt comms on their own networks. As long as they have control over one of the two ends of the communication, they can get access to the session key and then, to me, it's an implementation matter with their existing logging solutions to log that.

I'm not trying to trivialise the effort needed, but to suggest that there's no fundamental reason that they can' adapt existing solutions to address it, especially as we're not talking about some kind of near-term problem here. This will only come into focus when/if TLSv1.2 is deprecated and if the amount of places still supporting SSLv3 is anything to go by we're a really long way away from that.

So for me the idea of pushing things forward from a security standpoint at a protocol level somewhat outweighs the impact that organizations will need to modify their solutions over the course of the next say 10 years (that's a ballpark number I don't have a crystal ball that tells me when TLSv1.2 deprecation will occur) to address it.

[thwarted]

I view this as the banks want to get the experts who are working on the standard to sign-off on their requirements, so they can continue to say they are secure purely because they do what the standards say, and ignoring if the standard is actually increasing security or not.

There are very good reasons why you want to latch your regulations to a common, Internet standards body, especially when it comes to security (open, visible, accessible discussion is the primary reason, for me). But in that case, you don't also get to dictate that the goals of the wider Internet need to align with your industry's (short-term) business objectives, especially if they run counter to the goals of the Internet standards bodies. The Internet will continue on and make standards that are appropriate for itself, no matter what the banks do in this regard. Internet standards bodies are not in the business of securing internal bank networks, but if securing internal bank networks is important to banks, they are welcome to use Internet standards in order to do so.

The banks can just as well go back to having regulations on internal communications like they had before SSL and TLS existed if keeping up with Internet standards is too expensive financially or operationally. Or their regulations can say that TLS1.2 is an acceptable deployment for their internal networks. This, too, has costs, as the rest of the Internet deprecates old, insecure stuff. And one of those costs is that you cease being able to piggybank on the efforts of the wider Internet. That cost, over the long term, needs to be assessed by the banking industry too.

[KMag]

> If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key...

The point of "perfect" forward security is that it's not possible to recover session keys using only the secret key and the (logged) handshake data.

One solution would be to modify the server's stack to use kerberos or some other low-overhead encrypted channel to send the session keys to the logging server so that the session keys can be logged along with the encrypted data. Another, less scalable, solution would be to have a border proxy set up the TLS 1.3 session keys and then set up a connection from the border proxy to the internal server using TLS 1.3 PSK such that the internal and external connections use the same session key. Both of these solutions would allow a border proxy to decrypt and filter traffic without the overhead of having the border proxy decrypt and re-encrypt the traffic. The border proxy could decrypt and process traffic, and if no problems are found, forward the still-encrypted data to the internal server.

Yes, with TLS 1.3 it will be a pain to set up logs that make customer data more vulnerable to theft. It will still be possible, and multiple vendors will gladly implement it for banks and sell to banks.

[_0w8t]

In my experience the only thing the banking industry cares is convince for themselves.

For example, I heard exactly the same arguments against forward security. On surface they look reasonable with all the complains how it would be difficult to decrypt and re-encrypt again at end points to forward the traffic for scanning.

But then the same bank uses Akamai to defend against DoS and let Akamai decrypts all the traffic so the bank can use Acamai's infrastructure for caching and minimize load on own systems.

[wodencafe]

Put the cyber-snooping aspect aside for a minute.

Where have the banks been?

Why didn't this Andrew Kennedy guy (or any other banks) chime in when this was fresh?

Why did this only become relevant to them at the last minute? Forgive me, but I have no sympathy for these institutions. If they really cared about Security, they would have dealt with this nonsense a long time ago.

You want to excuse the banks because they are "big businesses [that] have regulations you don't understand or even care about", but for institutions where security is of critical importance, why haven't they been following this more closely?

This a case of pure neglect and greed.

[riskable]

Do not assume that the people who are responsible for monitoring such things (at the big banks) have only their employer's purse in mind.

One cannot rule out... <whistles with fingers in ears>

Someone's going to get vastly improved security whether they want it or not!

Protocols like TLS protect bank customers from fraud. It is the bank's duty first and foremost to protect their every day customers. If Wall Street always comes first banking's primary product will be despair.

[wodencafe]

> If Wall Street always comes first banking's primary product will be despair.

This has already come to be :)

[kabdib]

No surprise, given the quality of the edge software of most banking systems. With few exceptions, they are howlingly bad. I cannot imagine what the insides of them are like.

[wodencafe]

It's turtles all the way down.

[WhitneyLand]

I sense the response was somewhat less receptive for subjective reasons.

For example, his tone is too formal and sounds bureaucratic. He refuses to state his actual request until the end of a long winded description of his clout and authority.

I think people did listen but were turned off before he even got to the point.

edit: Oh dear. Just noticed he has a degree in political science and no development background. How can this end well for him?

[wtbob]

> For example, his tone is too formal and sounds bureaucratic. He refuses to state his actual request until the end of a long winded description of his clout and authority.

I see that as just being a professional adult. He states who he is, which implies why his opinion matters, then he states his opinion.

'Please don't do this kthxbye!!!1!cos(0)!!' is hardly more persuasive.

[WhitneyLand]

I see your point, but I think we have to account for the traditional business culture of software developers.

I think most in this culture lean toward informal speech, and toward stating your argument first and mentioning your credentials last, if at all.

I wanted to send him a private message with suggestions, but couldn't be sure it would be taken constructively and not be hurtful.

[daurnimator]

<not necessarily my views, but a lens to view the argument from:>

However regulation isn't static. Infact, TLS1.3 is likely to live on longer than any given set of government or industry regulations.

If old regulations have a dependency on TLS1.2, then they'll be stuck on that until they "upgrade"

[kybernetyk]

>Take this example: A regulation says...

Then the regulations are faulty and need updating to be on par with reality.

[askmike]

That is not how businesses manages risk, and even less how IT departments of businesses manage risk.

[xg15]

Because why? The idea that an organization shots be able to monitor its own traffic seems quite reasonable to me.

[tremon]

But the organization already can monitor its own traffic. At the source, before it is encrypted.

[johncolanduoni]

Unless the devices that need to be monitored are the endpoints. Do you really oppose the laws requiring banks to record all communication (including non-official channels) that goes in and out of their trader's computers? Or do you have an alternate solution that doesn't make circumventing it dramatically easier?

[tremon]

I'm not sure I follow what you're saying. I'm arguing that the banks should already be in full control of their endpoints, so I don't see why they can't perform the monitoring there. Nor do I think that banks should be facilitating the use of non-official channels for communication.

As for circumvention: are you concerned about ensuring a complete communication paper trail or protection from insider threats?

[tcoppi]

And if you don't have control of your endpoints, any network monitoring or tls mitm is meaningless anyway, as the contents can always be encrypted again inside of the tls tunnel. Then you're back to square one, the inbound/outbound traffic is inscrutable to monitoring.

[johncolanduoni]

The entire point of much of the legislation requiring monitoring of the communications of bank officials is to combat insider threats (though not to security in the usual sense). They're required to monitor all communication (i.e. not just official e-mail that can be easily monitored another way) so there is documentation if any of their employees does something funky (fraud, etc.).

In this case, the endpoint by necessity is physically accessible to the possible adversary, which means they have a whole host of methods for disabling monitoring software. It's much harder to interfere with a box which you don't have physical access to that is listening in on your communication, and which simply drops any data it cannot intercept.

[MertsA]

So my knowledge about how forward secrecy works in TLS is spotty to say the least but the server still has the decryption key in memory AFAIK. Why not sidestep the issue and just create a secure channel between the server and whatever middleboxes there are that need the key and just send the ephemeral key that way?

I get that this would be less secure to use in practice because now anyone who gets control over the server or the middleboxes or who can somehow compromise that secure channel between them can get at the shared secret but still, it would preserve forward secrecy. The only caveat is that the secure channel between the server and the middleboxes would also need forward secrecy but I don't really see how that is a problem.

Am I missing something obvious here?

[nindalf]

The person requesting this change controls neither the server nor the client. They control the intermediate network. If they could log the ephemeral keys it would solve the solution, but only the server and client hold that.

[michaelt]

As I understand it, if you don't have the server's private key it makes no difference whether a connection uses FS. FS merely means compromise of long-term keys does not compromise past session keys.

Surely for the presence of FS to be relevant, they must already have the server's private key, implying they do have control of the server?

[matt4077]

It does indeed make sense from his point of view. Unfortunately, there are some actors using the exact same perimeter "defense" who I'd gladly see frustrated, mostly governments east of of Poland.

I'm also hopeful that an increase in price of any MITM solutions that might get develop will put an end to such practices where they are abused for marginal utility: Universities, Hotels, Airports, ad-replacing proxies etc.

[kijin]

> it will simply be decrypted at the boarder [sic] of the business and routed internally unencrypted.

If the banks do this, it's their problem, and I hope the regulators will be very unhappy about it. There is no need to make the defaults less secure for billions of people in order to make it slightly cheaper for a few large corporations to implement an obviously correct alternative.

[ska]

The authors last point is strong though, if there is an industry body in an area that is affected by these standards, that body should have been involved in the standard process since (before the) beginning. Showing up late and saying "hey, that won't work for us" is pretty weak.

[je42]

There should internal standards to always encrypt; even internal traffic. Instead of just drop TLS altogether; they could at least reencrypt to a secure protocol that they still support.

[brians]

a) He's a troll. Look at his patterns around specific requests: he asks for something (an operator, an example), and when one's shown that doesn't count. His messages aren't signed with his name. It's textbook delay-and-befuddlement, right out of that old OSS field manual.

b) Why should I, as a bank account holder, value a bank that uses TLS 1.2 with decryption devices (after the release of TLS 1.3) more highly than one that uses no encryption at all?

[uola]

While I probably (haven't followed the issue closely) agree with him on the issue, the arrogance makes my blood boil. These academics and their dysfunctional standard agencies are the ones that should go down in history for how intelligence agencies could build unprecedented dossiers on civilians and despots could enforce their will by torturing journalists. If he thinks one can make a secure internet, something his organization has repeatedly shown itself incapable of doing, without having major players on board with your decisions he is delusional at best.

[4ad]

> After all, who doesn't have a bank account?

But rules and regulations shield me and give me legal and financial aid for the stupid thing my bank might do.

[lexman0]

True enough.

But those who steal your account information and use it to pose as you don't follow the rules and regulations.

[daenney]

And how does that relate to the fact that banks would like to have a weaker version of TLS 1.3? If a nefarious entity is stealing your data they're (probably) MITMing your connection with the bank, in which case TLS 1.3 is likely an improvement for you and the bank and so is the forward secrecy part. If it's more along the lines of social engineering then the whole TLS thing becomes moot.

Sure they might be inside the bank's network in which case being able to more easily decrypt traffic could help in sighting this kind of activity, but there's easier ways of stealing people's data and impersonating them than infiltrating a bank.

[4ad]

But the bank follows the regulations that tell it to give me all my money back, if there's some fraud. I don't have any money to lose if the bank does not implement security properly. Only the bank has to lose.

[pdpi]

They'll refund you after you've already lost the money, or the attacker might use the bank details as part of larger-scale identity theft that might come to leave you in hot water with law enforcement if he uses your identity to commit a crime. All that inconvenience is your own loss, and the bank paying damages for that doesn't really "fix it"

[cmdrfred]

>leave you in hot water with law enforcement if he uses your identity to commit a crime.

Officer Friendly: His social security card was found at the scene, so Mr.Smith must be guilty!

[angersock]

It isn't so much regulations as boneheadedly conservative internal IT. I've dealt with the same thing in healthcare.

The rest of us shouldn't suffer because it might mean slightly reduced profit margins for these bozos.

[drvdevd]

And like, when you put your box on a VLAN which goes through some DPI boxes which goes through some other stuff which is subject to some firewall policy ... guess what? It's still connected to the Internet.

[venomsnake]

Keyboard warrior here - almost any security solution I have heard of honors user installed CA above all else. Not sure about iOS. So decrypting traffic and MITM are still trivially possible on any device the admins have access to.

And MITM is the cornerstone of analysis. It may require spending money, or couple of megabytes more for storage of session keys, but at the end - you have the plaintext on your company devices.