[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.