
Industry Concerns about TLS 1.3 - Kliment
https://www.ietf.org/mail-archive/web/tls/current/msg21278.html
======
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?

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

------
madmax108
>>> My view concerning your request: no.

is probably the best response for the request.

On a related note though, it's always amazing how on one hand Big Banking
tries to show that it's in touch with the latest tech developments (Bitcoin
Consortiums, RFID/NFC payments) etc. but on the other hand display a very
shallow understanding of how secure systems should work.

~~~
rdtsc
I call it paper security or checklist security. Usually it is about
implementing enough to check off a list of requirements from some document.
Antivirus installed? Check (Nevermind it is a Linux box and AV loads a dubious
proprietary driver in the kernel with a huge attack surface and remote exploit
posibility because of how it does updates), such and such EAL-4 operating
system intalled? Check, and so on ...

So they tick all the boxes and in the end up with a worse off posture than if
they just stayed with defaults for example.

~~~
matt4077
As far I remember, major banks have been rather secure in the last decades,
especially compared to the hipster hackers at Yahoo/Dropbox/github/....

So maybe their checklist is worth a look.

~~~
rdtsc
You're right, that's fair. I can't remember a large bank was hacked as to
where their customer's money was stolen or anything like that. It is usually
retailers and such.

------
jrockway
I don't understand why the banks need to change TLS 1.3 to spy on their
employees. When I was working at a bank, there were literally no routes from
the Intranet to the Internet. Everything went through a proxy that blocked 95%
of the Internet. Had to run a proxy server on jrock.us in order to get
anything done. (They just bought the list of sites to block, and jrock.us
never ended up on it. Blacklisting, very good security technique...)

~~~
zigzigzag
The guy's rationale may be kind of dubious but it's clearly stated: there
aren't any tools that do DPI on TLS 1.3 sessions right now.

~~~
jrockway
You don't need to do deep packet inspection when you just MITM all the
traffic.

~~~
lisivka
MITM introduces significant delays, yet another single point of failure, adds
significant risk of leakage. Current DPI are passive, so they have no such
problems.

~~~
ivan_gammel
It's technical problem, that can be solved. Dedicated hardware optimized for
MITM, probably.

~~~
bchociej
It's already in use, in fact.

~~~
ChoHag
Who'd have thought banks would look for ways to save money?

Madness!

------
stephen_g
I think this request is pretty unreasonable, and anything that stops the
ability to passively snooping on TLS is a great thing.

I think there could be a security gain though in adding support for a better
way to actively MITM TLS traffic though - in having a proper mechanism for
filtering proxy firewalls. For some applications (say, school networks) it is
OK to monitor and filter traffic, but the way it is done now is terrible for
security. Usually this is by terminating the TLS at the proxy, scanning it,
and then re-encrypting it with an certificate automatically generated and
trusted by an internal CA (whose root certificate is installed on the
machines).

The huge problem is that now everyone has to trust all the root CAs installed
on the firewall, instead of being able to decide which ones to trust
themselves. The firewall has to also decide whether or not to trust self-
signed certificates.

Much better would be to be able to decrypt, re-encrypt with a certificate
issued by a real CA, and then also send the original certificate along with
the handshake. Then, the first time you visited a TLS site, it could pop up a
big warning saying 'This traffic is intercepted by firewall.institution.edu,
do you consent?' and have a little exclamation mark in the toolbar to always
indicate that it's being intercepted. The browser would have to trust both the
interception certificate (which encrypts between the firewall and the endpoint
inside the internal network) as well as getting the original certificate and
deciding whether to trust that (which you don't get now).

~~~
Tharkun
Why do you think it's ok to spy on your users on a school network?

~~~
ChoHag
The students didn't buy the computers. I did.

Edit: And before anyone starts with the "you shouldn't spy on your users"
bullshit: Bollocks. If you want that, welcome to laa laa fantasy land where we
all breathe sand.

You _will_ use computers or networks in which the operator is recording
everything you do. You can either work within that assumption, or you can
stick your fingers in your ears and pretend.

And no, I don't use my employer's[+] computer for anything personally-
sensitive and I don't install their shite on mine in order to access their
network and when I do use their computer I expect they will watch everything I
do even if they don't because I'm using their equipment. I do my real work on
my own computer or I don't do my work. The employer is well within its rights
to suck on it.

[+] There is no reason why the same should not apply to schools, libraries or
any other institution in which people are permitted to use items owned or
services controlled by others.

------
perlgeek
Isn't it pretty much standard for such organizations to have decrypting and
re-encrypting proxy, with their own CA that clients have to trust?

If they do, I don't see how forward secrecy changes much, and they just have
to tap the plain text from the proxy.

If they don't, I'm seriously surprised.

~~~
akvadrako
The original message does make dubious claims, but a little later in the
thread, the real issue becomes clear.

from
[https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-...](https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-
j-GPACvZw)

"With TLS 1.2 we can ask the end user to take a Wireshark trace and then
decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the
SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available.
Unfortunately, Microsoft does not allow this functionality, which is a problem
in a TLS 1.3 only environment."

As I understand their argument, if you control the server (and hence private
key and cipher suite) you can store the traffic without MITM and later decrypt
it if needed. With forward secrecy, that isn't possible.

~~~
ghshephard
If you control the server, you can decrypt any time you want, because
obviously if you were able to decrypt at one time, you can do so later.

~~~
akvadrako
That's the whole point of forward secrecy. For the one session you use a
temporary key which can't be recovered later. You can only decrypt the stream
if you store that key.

~~~
merb
well your proxy can just store everything in Plain Text? I mean if you really
need to decrypt it later you already saved it somewhere, however you can just
store the plain text since your proxy already has that?

------
knorker
> Exporting of ephemeral keys: This solution has scalability and security
> problems on large, busy servers where it is not possible to know ahead of
> time which session is going to be the important one.

I don't buy it.

You can store entire sessions worth of data, but can't also optionally save
metadata?

Yes, I realise you may not want to store it for all connections, but if you
don't want to have a "should I store" oracle inline with the connections, then
do it async and skip writing it do disk/storage service once the answer comes
back.

------
pmarreck
Well, _that_ was kind of a burn.

Was the argument by the bankers basically a complaint that retooling would be
very expensive? and/or that employee surveillance would be more difficult?
(yeah, I'm sure _everyone_ is a fan of that!)

~~~
brazzledazzle
mitm surveillance of employee traffic is basically a cornerstone of enterprise
security since those networks are designed to be very squishy on the inside.
Thankfully Google is turning the assumption that the perimeter needs to extend
to your rather vulnerable clients on its head but that will be several years
before it's productized enough that middle managers will be convinced to buy
it by a VAR over a game of golf.

~~~
ChoHag
That's basically putting the cart before the horse.

Security is hard. Hard problems are easier when there are fewer of them. It's
easier to build one big wall than lots of little ones.

Surveillance of employees is a cornerstone of enterprise security because
humans are inherently untrustworthy. One part of the solution to this problem
is to define a distinction (using golf[+] of all things as an analogy) between
the rough, the fairway and the green. Because defining a border between the
rough and the course is easy, and untrustworthy humans aren't all that bad
most of the time, the distinction between the fairway and the green easily
becomes blurred.

While employers may polish up the distinction between their workaday desktops
and their locked-down servers they will never abandon the difference, and nor
should they, between _their_ systems and _everyone else 's_ systems.

[+] You have my permission to use this analogy with your manglers.

~~~
brazzledazzle
Just to be clear I'm referring to monitoring traffic for security threats. Not
for things like stealing source code or applying for jobs or whatever BS some
employers are paranoid about.

The reason it's a cornerstone is because your clients, especially laptops, are
huge gaping attack vectors. They visit other networks and browse the web. Even
if they're browsing the web 100% of the time through a web proxy it's not
going to catch everything.

And it's for that same reason Google decided to shrink their perimeter. The
distinction between their systems and someone else's is still maintained, but
they've accepted and embraced the fact that the laptops used by their
employees can and will get owned. So instead of acting as a bridge between the
internet and internal squishy networks they sit out there with the internet.

But I'm hardly doing the concept justice. In fact I'm probably hurting it more
than helping it. If you haven't read it Google discusses the security concepts
in a short paper you can get here:
[http://research.google.com/pubs/pub43231.html](http://research.google.com/pubs/pub43231.html)

------
akvadrako
A more readable link:

[https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr...](https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA)

------
anonymousDan
I don't quite get what they are currently doing. Is it that they have some
kind of Internal mitm proxy that proxies every TLS session with external
hosts, recording the conversation for later offline analysis? Why wouldn't
they still be able to do that? Or are they just worried about their ability to
intercept internal conversations? I'd be really interested to know what a
typical bank security architecture looks like, does anyone have a reference
for further reading perhaps?

~~~
4ad
They don't MITM, they record sessions and later decrypt out-of-band as needed.

With TLS 1.3, they would need to MITM, which require infrastructure changes
and potentially affects the performance.

They are complaining TLS 1.3 forces them to do work they otherwise wouldn't
have to do.

~~~
anonymousDan
But how doe they get access to the keys for the session without modifying the
end hosts or MITM'ing the traffic?

~~~
4ad
> without modifying the end hosts

They have full control of the end hosts. That's why the group policy forces
you to use Internet Explorer instead of letting you use Firefox.

~~~
anonymousDan
Hmm, but why can't they just then record the session keys as before even for
forward secure TLS (presuming we are talking about clients inside the bank
initiating TLS sessions to external parties)?

~~~
ChoHag
Ah well they're banks you see and "doing things" requires spending money which
they're rather averse to.

Also never use the word just outside the context of law.

------
kbart
_" Like many enterprises, financial institutions depend upon the ability to
decrypt TLS traffic to implement data loss protection, intrusion detection and
prevention, malware detection, packet capture and analysis, and DDoS
mitigation. Unlike some other businesses, financial institutions also rely
upon TLS traffic decryption to implement fraud monitoring and surveillance of
supervised employees."_

I'm at lost here. What's the point of having TLS if it can be easily
decrypted? Why not to ditch it altogether then? All this argument sounds
somewhat fishy, just because your practices rely on insecure behavior, it
doesn't mean it shouldn't be fixed for the rest of us.

~~~
lisivka
TLS can be decrypted with private key. Just keep your private key secret. For
example, this feature is useful for debugging TLS encrypted communication with
server by capturing data and decrypting it using WireShark. Forward secrecy
breaks that.

~~~
anonymousDan
Ok I'm missing something here. If an internal bank employee initiates a TLS
session to an external service, the only key the bank could hope to access is
the session key if it has control over the end host, in which case it can just
store the session key for each connection. What private key are you referring
too if not the session key?

------
heisenbit
It may well be that from a business perspective a greater threat to banking is
coming from insiders, failing systems and incompetence than from outsiders
exploiting TLS weaknesses. To those wondering why banks are worried about
their employees communication even internally keep in mind that there have
been very expensive judgements related to banking employees conspiring to
break legal or other regulatory rules.

The alternative namely monitoring on the end points is hard to implement
comprehensively and a lot more expensive.

If (and that is a big iff) the banking use case really justifies a special and
weaker transport protocol then maybe it should be upon the banks bear the
whole cost of doing that. It would also clearly assign the responsibility when
things may fail from a security perspective. Maybe the end point alternative
looks then more attractive.

------
chetanahuja
_"...almost all of whom are running TLS internally and have significant,
security-critical investments in out-of-band TLS decryption. Like many
enterprises, financial institutions depend upon the ability to decrypt TLS
traffic to implement data loss protection, intrusion detection and prevention,
malware detection, packet capture and analysis, and DDoS mitigation. Unlike
some other businesses, financial institutions also rely upon TLS traffic
decryption to implement fraud monitoring and surveillance of supervised
employees."_

And thus essentially defeating the entire purpose of TLS. Can you please help
us continue doing this with the new version of TLS too. Thanks. Love. Big
Banks.

~~~
rincebrain
Only sometimes.

The argument here could be whether you, as an individual working for an
employer on employer-controlled hardware, have the right to communications
that cannot be viewed by the employer at their discretion on those systems.

Having that capability (undecryptable communication) on an exceptional basis
(e.g. only a few sites or methods do it) might be grounds for blocking any
instances of the protocol that negotiate that level at the border.

Having every secure site do it would result in not being able to passively
store and only decode the communications that, say, you have occasion to go
inspect later for discovery reasons, and instead would require MITMing and
downgrading all connections (and storing the traffic, at best, re-encrypted
with a different key).

(Note that I'm not voicing an opinion on the topic, just observing that there
are legitimate reasons to desire this functionality from several perspectives,
which do not necessarily imply wanting a backdoor in the protocol in the
general case.)

~~~
PeterisP
From a technical standpoint, the desire of <bank> to monitor all
communications of a stockbroker in an easy and effective manner and being able
to decrypt historical captured is identical to the desire of <evil government>
to do the same for their civil rights activists.

From a protocol perspective, you can't distinguish it - any new protocol
either makes monitoring harder for everyone or easier for everyone, without
checking if your reason is good or bad.

If we choose to make communications more private, then yes, the ability to
monitor stuff will suffer even if someone has a legitimate and reasonable
reason to need this ability. Too bad, we've made a choice that the security of
the masses is more important than this. I acknowledge that this change will
hurt the banks for the reasons given above, but in this case hurting them is
an unavoidable cost of helping most everyone else.

~~~
rincebrain
Sure, from a protocol perspective, arranging it so nobody, even the original
owner, can decrypt the communication after the fact is beneficial, except that
now, you end up with people downgrading such communications or storing the
session secret keys, the latter probably by patching software crypto
implementations where possible (since I doubt any of the major crypto
implementations would agree to storing those keys even with an --i-am-a-
developer-really-stop-bothering-me flag).

I hope I'm wrong. I don't want to end up in a world where all enterprises
actively MITM and negotiate down to non-PFS protocols to avoid this, or hack
up the software stacks on their machines to circumvent this (with all the
overhead that implies - echoes of "requires Internet Explorer 5" for how old
some of this will probably get between updates).

I just don't think that the people who make use of this functionality are
going to let it go, no matter what it takes.

(That's not to say it's not worth trying, to be clear - I just foresee it
ending poorly for everyone except for private individuals, and possibly even
them if ISPs start requiring you accept their MITM CA.)

------
shthed
Late to the party.. heh, they agreed to remove RSA Key Transport back in April
2014, implemented in draft 02

[https://www.ietf.org/mail-
archive/web/tls/current/msg12266.h...](https://www.ietf.org/mail-
archive/web/tls/current/msg12266.html)

> The consensus in the room at IETF-89 was to remove RSA key transport from
> TLS 1.3. If you have concerns about this decision please respond on the TLS
> list by April 11, 2014.

[https://threatpost.com/tls-1-3-working-group-has-
consensus-t...](https://threatpost.com/tls-1-3-working-group-has-consensus-to-
deprectate-rsa-key-transport/105916/)

[https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8...](https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8628f39063ebf580fafe04e7)

------
saurik
Welcome to almost two weeks ago? Given how many people seem to be upvoting and
commenting on this link, was everyone else on vacation for some holiday I
don't celebrate when this came up multiple times before?

[https://news.ycombinator.com/item?id=12560284](https://news.ycombinator.com/item?id=12560284)

[https://news.ycombinator.com/item?id=12561004](https://news.ycombinator.com/item?id=12561004)

[https://news.ycombinator.com/item?id=12563481](https://news.ycombinator.com/item?id=12563481)

~~~
veeti
This had a much catchier, editorialized title earlier.

------
avar
Here's the exchange, I found this hard to read without word-wrapping:

    
    
        > On 22 Sep 2016, at 20:27, BITS Security <BITSSecurity at fsroundtable.org> wrote:
        > 
        > To:  IETF TLS 1.3 Working Group Members
        > 
        > My name is Andrew Kennedy and I work at BITS, the technology policy
        > division of the Financial Services Roundtable
        > (http://www.fsroundtable.org/bits).  My organization represents
        > approximately 100 of the top 150 US-based financial services
        > companies including banks, insurance, consumer finance, and asset
        > management firms.
        >
        > I manage the Technology Cybersecurity Program, a CISO-driven forum
        > to investigate emerging technologies; integrate capabilities into
        > member operations; and advocate member, sector, cross-sector, and
        > private-public collaboration.
        >
        > While I am aware and on the whole supportive of the significant
        > contributions to internet security this important working group has
        > made in the last few years I recently learned of a proposed change
        > that would affect many of my organization's member institutions: the
        > deprecation of RSA key exchange.
        >
        > Deprecation of the RSA key exchange in TLS 1.3 will cause
        > significant problems for financial institutions, almost all of whom
        > are running TLS internally and have significant, security-critical
        > investments in out-of-band TLS decryption.
        >
        > Like many enterprises, financial institutions depend upon the
        > ability to decrypt TLS traffic to implement data loss protection,
        > intrusion detection and prevention, malware detection, packet
        > capture and analysis, and DDoS mitigation.  Unlike some other
        > businesses, financial institutions also rely upon TLS traffic
        > decryption to implement fraud monitoring and surveillance of
        > supervised employees.  The products which support these capabilities
        > will need to be replaced or substantially redesigned at significant
        > cost and loss of scalability to continue to support the
        > functionality financial institutions and their regulators require.
        >
        > The impact on supervision will be particularly severe.  Financial
        > institutions are required by law to store communications of certain
        > employees (including broker/dealers) in a form that ensures that
        > they can be retrieved and read in case an investigation into
        > improper behavior is initiated.  The regulations which require
        > retention of supervised employee communications initially focused on
        > physical and electronic mail, but now extend to many other forms of
        > communication including instant message, social media, and
        > collaboration applications.  All of these communications channels
        > are protected using TLS.
        >
        > The impact on network diagnostics and troubleshooting will also be
        > serious.  TLS decryption of network packet traces is required when
        > troubleshooting difficult problems in order to follow a transaction
        > through multiple layers of infrastructure and isolate the fault
        > domain.  The pervasive visibility offered by out-of-band TLS
        > decryption can't be replaced by MITM infrastructure or by endpoint
        > diagnostics.  The result of losing this TLS visibility will be
        > unacceptable outage times as support groups resort to guesswork on
        > difficult problems.
        >
        > Although TLS 1.3 has been designed to meet the evolving security
        > needs of the Internet, it is vital to recognize that TLS is also
        > being run extensively inside the firewall by private enterprises,
        > particularly those that are heavily regulated.  Furthermore, as more
        > applications move off of the desktop and into web browsers and
        > mobile applications, dependence on TLS is increasing.
        >
        > Eventually, either security vulnerabilities in TLS 1.2, deprecation
        > of TLS 1.2 by major browser vendors, or changes to regulatory
        > standards will force these enterprises - including financial
        > institutions - to upgrade to TLS 1.3.  It is vital to financial
        > institutions and to their customers and regulators that these
        > institutions be able to maintain both security and regulatory
        > compliance during and after the transition from TLS 1.2 to TLS 1.3.
        >
        > At the current time viable TLS 1.3-compliant solutions to problems
        > like DLP, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and
        > monitoring of regulated employee communications appear to be
        > immature or nonexistent.  There are serious cost, scalability, and
        > security concerns with all of the currently proposed alternatives to
        > the existing out-of-band TLS decryption architecture:
        >
        > - 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.
        >
        > - Exporting of ephemeral keys: This solution has scalability and
        >   security problems on large, busy servers where it is not possible
        >   to know ahead of time which session is going to be the important
        >   one.
        >
        > - Man-in-the-middle: This solution adds significant latency, key
        >   management complexity, and production risk at each of the needed
        >   monitoring layers.
        >
        > Until the critical concerns surrounding enterprise security,
        > employee supervision, and network troubleshooting are addressed as
        > effectively as internet MITM and surveillance threats have been, we,
        > on behalf of our members, are asking the TLS 1.3 Working Group to
        > delay Last Call until a workable and scalable solution is identified
        > and vetted, and ultimately adopted into the standard by the TLS 1.3
        > Working Group.
        >
        > Sincerely,
        > 
        > Andrew Kennedy
        > Senior Program Manager, BITS
    

The reply:

    
    
        To: BITS Security <BITSSecurity at fsroundtable.org>
        Subject: Re: [TLS] Industry Concerns about TLS 1.3
        From: "Paterson, Kenny" <Kenny.Paterson at rhul.ac.uk>
        Date: Thu, 22 Sep 2016 19:14:25 +0000
        [...]
    
        Hi Andrew,
        
        My view concerning your request: no.
        
        Rationale: We're trying to build a more secure internet.
        
        Meta-level comment:
        
        You're a bit late to the party. We're metaphorically speaking at the
        stage of emptying the ash trays and hunting for the not quite empty
        beer cans.
        
        More exactly, we are at draft 15 and RSA key transport disappeared
        from the spec about a dozen drafts ago. I know the banking industry is
        usually a bit slow off the mark, but this takes the biscuit.
        
        Cheers,
        
        Kenny

------
amluto
I don't get it. This can't be about decrypting traffic between internal
clients and external servers, because the bank doesn't have the RSA key in the
first place. It also seems unlikely that it's about decrypting traffic between
external clients and internal servers, because (a) that's not what the bank
rep said and (b) the server would just log the traffic.

That leaves two cases: internal client <-> internal server and internal client
<-> internal MITM. For both of these cases, I see two easy solutions:

1\. Log the session key.

2\. Define a custom TLS extension that contains the session key encrypted with
against a known bank-controlled public key and have the server/MITM send this
extension after the handshake. Problem solved.

In any event, the internal client <-> external server case is highly
problematic. What's to stop, say, Snapchat from running an extra
unauthenticated DH exchange in JavaScript and encrypting all the application
layer traffic against the resulting session key? The MITM proxy won't notice
unless it's very clever indeed and then all those nice MITM proxy logs are
useless.

------
phkamp
This is exactly the clash between governments (here financial regulation) and
cyberlibertarians I wrote about earlier this year:

[http://queue.acm.org/detail.cfm?id=2904894](http://queue.acm.org/detail.cfm?id=2904894)

What have we gained in security, if TLS1.3 is basically illegal to use for
banks ?

Who wins if browsers refuses to connect to web-banking which operates inside
the boundaries of the law ?

~~~
aseipp
But they're claiming it will require overhauling their infrastructure and cost
money to do -- not that it's impossible to support, or that TLS 1.3 will "be
illegal" if their demands are not met (this is just nonsense and 100% FUD on
part of your comment, honestly -- and I say that as someone who thinks highly
of your work). Furthermore there's no clear evidence TLS 1.2 will be
deprecated anytime soon, so these people have years to sort out the details
with their vendors to have replacements in-flight. Banks have money and
connections. They'll survive this and evolve.

In any case, they could have made their concerns available earlier to the
standards body. Like, over two and a half years ago (RSA key exchange was
removed in early 2014). This is hardly the fault of "cyberlibertarians" or
whatever, this is just these people being out of touch. The alternative here
would be that these guys get to butt into the standardization process and
demand changes at the very last moment, after years of work, with no negative
impacts or consequences for them -- for what is ultimately a small portion of
the overall internet.

Why would we want that? It completely undermines the authority of the IETF and
the entire point of a standards process if "really important" people can just
completely railroad it and demand changes on a whim with no consequences to
themselves. Frankly, completely ignoring the actual _content_ of the request,
this alone is pretty bad behavior on their part.

Why we should worsen the security of billions of people, and introduce
complexity into a vital internet protocol, so that those dorks can have
slightly higher profit margins -- I dunno. Designing a security protocol is
hard enough. If they didn't want to pay attention to the conversation, and now
want to cry their pockets will take a hit -- well, maybe they'll learn and be
more proactive next time and save themselves some cash.

> Who wins if browsers refuses to connect to web-banking which operates inside
> the boundaries of the law ?

Nobody ever said TLS 1.3 would be illegal for banks, that browsers are going
to immediately drop TLS 1.2 after this (both of these two being a requirement
for your prediction to be true -- lol, and also completely asinine) making it
refuse to connect to a "law abiding bank", or that moving to TLS 1.3 would be
literally impossible for them forever and can't be solved.

This is just complete FUD dude, c'mon. Unless you're actually interested in
the answers to completely nonsense hypotheticals made up out of thin air, I
guess...

~~~
ChoHag
Thankyou for giving possibly the only coherent argument against this.

------
Nursie
While they were very late to the party, this is important for some sectors.
Not the reliance on specific tech (RSA) but being able to go back and decrypt
their own traffic later, with appropriate keys.

They need to routinely spy on some of their people,amd trace what happens to
their money. Not sure why this is a problem. Their use-cases are different to
(say) a user of Signal.

~~~
askmike
> They need to routinely spy on some [..] people

Unfortunately this is very far removed from the goals of the IETF, who is
striving for a more secure internet.

------
winteriscoming
I never knew that it was an accepted practice to have MITM techniques for
monitoring activities in cases like the author notes in that thread. I'm not
an expert but is this common? I haven't heard something like this before.

------
CDokolas
Well, North Korea is not complaining about TLS 1.3, why would banks have to?
Their proxy servers are already MITM platforms that meet their needs for
security.

~~~
askmike
Probably because Bank employees/customers use modern browsers/devices which
will at some point drop support for anything but TLS 1.3. I don't think this
will happen in North Korea.

------
FuckOffNeemo
Wouldn't this be solved by having multiple SSL offload reverse proxies at the
points you want to decrypt traffic?

