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