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