Subject: [TLS] Industry Concerns about TLS 1.3

From: BITS Security <[email-masked]>
Date: Thu, 22 Sep 2016 17:19:48 +0000

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

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 22 Sep 2016 18:36:08 +0000

This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

________________________________
From: TLS <[email-masked]> on behalf of BITS Security <[email-masked]>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: [email-masked]
Subject: [TLS] Industry Concerns about TLS 1.3

Sincerely,

Andrew Kennedy

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Thu, 22 Sep 2016 12:06:25 -0700

> 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 chang…

You've "recently learned" about a change that was proposed several
*years* ago, starting in the earliest drafts of TLS 1.3. This change
is being made due to substantial security issues with encryption based
key exchanges: while we could redesign the exchange to repair these
issues, the risk of key compromise resulting in decryption of old data
is real.

> 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 tha…

Let's get specific about how this works: if an employee of a regulated
institution is logging into a TLS protected social media website, how
do you decrypt the connection without using a MITM device on the
network? I'm sure with large enough checks collaboration application
providers will be happy to implement whatever you need in the way of
logging at the server.

> 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 transac…

This can be solved by logging the entire connection contents at the
endpoint. I don't understand how you say that this is not a
replacement: it's literally the same data as you obtain decrypting the
session. This is a requirement that many of the companies involved in
the TLS 1.3 process have also, and they haven't complained about it.
Maybe I don't understand what architecture you have which makes this
impossible. If you have too much volume, then I don't see how your
network appliance doesn't have the same problem. If it's intermittent,
and you didn't log verbosely on errors, set up the endpoint to log the
next fault, and wait.

> 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 instit…

Browsers haven't even succeeded in killing SSL 3.0 yet. I think you
have much more time then you think to stay on TLS 1.2.

> -  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 monito…

And firing isn't enough of a threat to get people to behave when it
comes to circumventing monitoring?

> 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,…

Critical to whom? Not me. If you want to propose a solution that works
please do so. But don't pretend your problems are our problems.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Paterson, Kenny" <[email-masked]>
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 

> On 22 Sep 2016, at 20:27, BITS Security <[email-masked]> wrote:
>

---

From: Kyle Rose <[email-masked]>
Date: Thu, 22 Sep 2016 15:17:23 -0400

On Thu, Sep 22, 2016 at 1:19 PM, BITS Security <
[email-masked]> wrote:

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

I do not think this difficulty should be a consideration for TLS. These
capabilities can be enabled by the endpoint.

Kyle

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Sep 2016 19:18:34 +0000

+1 to what Kenny said.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Dave Garrett <[email-masked]>
Date: Thu, 22 Sep 2016 15:29:42 -0400

Mandating forward secrecy for TLS 1.3+ has been a strong consensus of this working group, so there's no point in myself or any other contributors just mass-replying with a big "no" here. That said, there is one puzzling thing I'm curious about:

> 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 tha…

Yes, all of these other channels are protected using TLS... which you do not control in any way. Also, many sites/services already prioritize FS cipher suites, so the deprecation of plain RSA key exchange doesn't actually affect the vast majority of people. (e.g. Facebook & Twitter both prefer ECDHE with NIST P-256) Within this very argument is already the argument that supervision at endpoints is required here. The security on the pipe is irrelevant. I don't see how you can make a point to bring this up but think keeping plain RSA KE suites is a useful solution.

Dave

---

From: BITS Security <[email-masked]>
Date: Thu, 22 Sep 2016 20:13:45 +0000

Yuhong-Thank you for the response.  

Our thinking here is that enterprises who use content delivery networks will have the end-user session hidden from them. 

The session from the end user to the edge of the content delivery network will be a different session than the one from the enterprise sees.  The IP's and ports will be different, the TCP layer activity like retransmissions will be different, and because of caching the application layer will be somewhat different.  There will be times when we need packet level data from the End User and TLS decryption of this packet level data for troubleshooting. 

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.  

-Andrew

From: Yuhong Bao [mailto:[email-masked]] 
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <[email-masked]>; [email-masked]
Subject: Re: Industry Concerns about TLS 1.3

________________________________________
From: TLS <[email-masked]> on behalf of BITS Security <[email-masked]>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: [email-masked]
Subject: [TLS] Industry Concerns about TLS 1.3 

 

Sincerely,

Andrew Kennedy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Sep 2016 23:19:49 +0300

Hi, Andrew.

Thank you for bringing these concerns to the list. I agree with Kenny that this is rather late, but it’s also true that I don’t think it would change the outcome of the consensus in this working group.

The quest to mandate FS in TLS-using applications goes back longer than this effort:
 - HTTP/2 (RFC 7540) has mandated it since draft -10 from February 2014.
 - The TLS BCP (RFC 7525) has mandating a preference for FS since version -00 or the individual submission (September 2013) and version -10 of the draft (February 2015) made the RSA key exchange a SHOULD NOT.

The latter is very significant, because that RFC is a bunch of recommendations for legacy applications.

I’m sympathetic to the argument about trouble-shooting the network, but not so much to the argument about keeping records.  I’ve taken the liberty of snipping most of your message, and interspersing my remarks with the parts where you shoot down proposed solutions.

> On 22 Sep 2016, at 8:19 PM, BITS Security <[email-masked]> wrote:

<snip />

> -  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 monito…

That is true, but from my admittedly limited exposure to financial institutions, the employees there then to be given extremely locked-down workstations where they have practically no ability to install or uninstall anything. The mobile phone revolution actually helps to make this palatable, as employees get to do their personal business on their personal phones using the cellular rather than the employer’s network. 

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

This seems like a strange claim to me. On the one hand, you’re storing away the entire (encrypted) content of the TLS session. On the other hand you can’t scale the storage of a few dozen bytes of keys for each of those sessions?

> -  Man-in-the-middle:  This solution adds significant latency, key management complexity, and production risk at each of the needed monitoring layers.

And yet many content providers use such solutions as part of their production network. I’m not even talking about TLS proxy firewalls. I’m talking about so-called “SSL offload” gateways such as F5’s big-ip. They decrypt everything on the gateway and forward the requests to back-end servers. It does add complexity, but so does your regular monitoring hardware.

> 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,…

If you can come up with something that will do all that without giving up on forward secrecy, I’ll be happy to help you write a draft.

Yoav

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 22 Sep 2016 20:57:36 +0000

Adding Andrei Popov.

________________________________
From: BITS Security <[email-masked]>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; [email-masked]
Subject: RE: Industry Concerns about TLS 1.3

-Andrew

Sincerely,

Andrew Kennedy

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Sep 2016 21:22:11 +0000

Hi Andrew,

?  Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment.
The best approach would be for Microsoft customers to make a feature request through their support channel.

Cheers,

Andrei

From: Yuhong Bao [mailto:[email-masked]]
Sent: Thursday, September 22, 2016 1:58 PM
To: BITS Security <[email-masked]>; [email-masked]; Andrei Popov <[email-masked]>
Subject: Re: Industry Concerns about TLS 1.3

Adding Andrei Popov.

________________________________
From: BITS Security <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; [email-masked]<mailto:[email-masked]>
Subject: RE: Industry Concerns about TLS 1.3

-Andrew

From: Yuhong Bao [mailto:[email-masked]]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Industry Concerns about TLS 1.3

________________________________________
From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of BITS Security <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] Industry Concerns about TLS 1.3

Sincerely,

Andrew Kennedy

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Xiaoyin Liu <[email-masked]>
Date: Thu, 22 Sep 2016 21:34:04 +0000

I created a feature request on Microsoft Edge UserVoice: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/16310230-ssl-key-logging-aka-sslkeylogfile

Best,
Xiaoyin

________________________________
From: TLS <[email-masked]> on behalf of Andrei Popov <[email-masked]>
Sent: Thursday, September 22, 2016 5:22 PM
To: Yuhong Bao; BITS Security; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Hi Andrew,

>  Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment.

Cheers,

Andrei

Adding Andrei Popov.

-Andrew

Sincerely,

Andrew Kennedy

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 22 Sep 2016 19:41:00 -0400

If the problem is the use of forward secrecy then there is a simple
solution, don't use it.
That is, you can, as a server, have a fixed key_share for which the secret
exponent becomes the private key exactly as in the RSA case. It does
require some careful analysis, though.

But maybe I misunderstood the problem and maybe I should not be putting
these surveillance-friendly ideas in people's minds...

Hugo

On Thu, Sep 22, 2016 at 1:19 PM, BITS Security <
[email-masked]> wrote:

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

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 22 Sep 2016 16:50:16 -0700

> require some careful analysis, though.

I think that this may be possible for TLS1.3 0-RTT data, but not for other
data where an ephemeral key will be generated based also on a parameter
that the client chooses.

-- 
Colm

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 22 Sep 2016 19:59:44 -0400

One of the most interesting chapters in the ultra-interesting history of
public key cryptography is that all of the Fathers of Public Key
Cryptography,  Diffie, Hellman, Rivest, Shamir and Adelman missed the
observation that from a (unauthenticated) DH key exchange you can get an
encryption scheme just by fixing one of the exponents. It was Taher
ElGamal, a few years later that made that observation and that is why this
encryption is known as ElGamal encryption.

As for the comment below:

On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh <[email-masked]>
wrote:

>> That is, you can, as a server, have a fixed key_share for which the
>> secret exponent becomes the private key exactly as in the RSA case. It does

The key_share contributed by the client is indeed ephemeral and it replaces
the random key chosen by the client in the RSA-based scheme.

Hugo​

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 22 Sep 2016 19:04:07 -0700

On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk <[email-masked]>
wrote:

>> I think that this may be possible for TLS1.3 0-RTT data, but not for
>> other data where an ephemeral key will be generated based also on a
>> parameter that the client chooses.
>>
>
> The key_share contributed by the client is indeed ephemeral and it
> replaces the random key chosen by the client in the RSA-based scheme.
>

Yep, you're right, now I get it. I also now wonder if clients should make a
best effort of detecting duplicate parameters and rejecting them.

-- 
Colm

---

From: Thijs van Dijk <[email-masked]>
Date: Fri, 23 Sep 2016 09:35:27 +0200

On 23 September 2016 at 04:04, Colm MacCárthaigh <[email-masked]> wrote:

> Yep, you're right, now I get it. I also now wonder if clients should make
> a best effort of detecting duplicate parameters and rejecting them.
>

Regular clients, no.
But this would be a useful addition to debugging / scanning suites (e.g.
Qualys), or browser extensions for the security conscious (e.g. CertPatrol).

-Thijs

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Sep 2016 09:05:51 +0100

> This also reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

Yuk. Prioritising the needs of those debugging networks
over the maybe 5-6 orders of magnitude more folks using
them is ass-backwards IMO. That result looks to me like
a very bad decision if I'm following it correctly.

S.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 23 Sep 2016 12:46:37 +0200

> a very bad decision if I'm following it correctly.

That's a very different concern than the one asked by BITS security,
and is IMO a very valid one. Running any protocol under TLS wouldn't
mean that debugging is very hard or impossible for the one running the
protocol. Administrators debug and trace protocols every day to figure
out failures (that's why we have advanced tools like wireshark). Making
it hard for them to use these tools isn't increasing security; it is
only making their life harder.

regards,
Nikos

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Sep 2016 11:59:31 +0100

> only making their life harder.

Sure. But their/our lives sometimes should be a bit harder
to make things safer for the vast bulk of people using the
networks/applications we're developing. As with everything,
there's a balance needed. In this case, I think the wrong
decision was reached.

S.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 23 Sep 2016 15:41:14 +0200

> there's a balance needed. In this case, I think the wrong

those secret keys are on the client machines and they will stay on client 
machines

making it hard to extract master key from process memory is just security 
through obscurity, not something that will stop a determined attacker

*cough*LD_PRELOAD*cough*
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 14:09:36 +0000 (UTC)

>a very bad decision if I'm following it correctly.
Brings to mind the story about the people who were so concerned about having the engine stolen out of the car that they bolted the hood shut so you could never get in.   So, of course, if there was any maintenance to be done to the engine, if was impossible.
I wonder if there is some need for balancing of requirements.
Nalini

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 23 Sep 2016 14:46:57 +0000

From the perspective an Enterprise that runs these applications and has invested HEAVILY in the debugging networks.........

The reason we are debugging these networks is so that "The 5-6 order of magnitude of folks using them"  will have good service.   If they do not,  they will consider competitors and/or generate a litany service calls or complaints.        I.E.     When these "Folks"  are slow or not working they are just as unhappy as we are.  

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, September 23, 2016 4:06 AM
To: Yuhong Bao <[email-masked]>; BITS Security <[email-masked]>; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On 22/09/16 19:36, Yuhong Bao wrote:
> This also reminds me of 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

Yuk. Prioritising the needs of those debugging networks over the maybe 5-6 orders of magnitude more folks using them is ass-backwards IMO. That result looks to me like a very bad decision if I'm following it correctly.

S.

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 23 Sep 2016 10:55:27 -0400

> The reason we are debugging these networks is so that "The 5-6 order of magnitude of folks using them"  will have good service.   If they do not,  they will consider competitors and/or generate a l…

Isn't that the market operating as expected? Those who deliver a
stable product at a competitive price are rewarded, while those who
fail to deliver or deliver at an unreasonable cost are not? (Some hand
waiving).

If all providers failed to deliver or delivered an inferior product,
then it might indicate a major course correction is needed. But I
don't think that's the case here.

Jeff

---

From: Dan Brown <[email-masked]>
Date: Fri, 23 Sep 2016 15:14:33 +0000

Weaker crypto to stop insider attacks, is that the request? (And practice?) Doesn’t that increase the risk of larger (but perhaps rarer) further insider attacks?

From: TLS [mailto:[email-masked]] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

If the problem is the use of forward secrecy then there is a simple solution, don't use it.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 23 Sep 2016 15:31:45 +0000

I am not sure I understand what your reply means?   

Is it that we should create or even allow an environment to develop,  where all providers of service cannot  provide effective diagnostics and support?   And then see the constituents of these industries collapse together.     And only then realize we have an issue?      
I hope I am  not understanding correctly.     IETF is supposed to be looking ahead to provide better answers and circumvent predictable problems.    Not ignoring,  waiting and then reacting to negative situations that can and should be avoided.  

What I am saying,  in relation to your "Delivering a stable product"  comment is that over time various industries have learned what it takes to "Deliver a stable product".    We did not want to invest millions in these debugging networks.   But  we learned the hard way,  that it was necessary.  
I am not a member of the banking coalition that started this subject,  nor of the banking industry at all,  but I certainly understand their perspective and am concerned about  the same unmanageable future they described.  

Thanks

Mike

-----Original Message-----
From: Jeffrey Walton [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 10:55 AM
To: Ackermann, Michael <[email-masked]>
Cc: BITS Security <[email-masked]>; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

> The reason we are debugging these networks is so that "The 5-6 order of magnitude of folks using them"  will have good service.   If they do not,  they will consider competitors and/or generate a l…

Isn't that the market operating as expected? Those who deliver a stable product at a competitive price are rewarded, while those who fail to deliver or deliver at an unreasonable cost are not? (Some hand waiving).

If all providers failed to deliver or delivered an inferior product, then it might indicate a major course correction is needed. But I don't think that's the case here.

Jeff

---

From: Watson Ladd <[email-masked]>
Date: Fri, 23 Sep 2016 08:43:46 -0700

> I hope I am  not understanding correctly.     IETF is supposed to be looking ahead to provide better answers and circumvent predictable problems.    Not ignoring,  waiting and then reacting to nega…

What exactly is the problem you are concerned with? As I've pointed
out previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting proxy.
What information does this not get you that you need on the network?

> I am not a member of the banking coalition that started this subject,  nor of the banking industry at all,  but I certainly understand their perspective and am concerned about  the same unmanageabl…

Do  Akami, Cloudlflare and Google magically not have these problems?

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 23 Sep 2016 16:49:05 +0000

Without re stating the original message from the bank coalition,  which states this better than I could,   the client and MITM solutions are not practical in many situations.    Also they do not provide the scope, depth or detail that is utilized with today's solutions.   

-----Original Message-----
From: Watson Ladd [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 11:44 AM
To: Ackermann, Michael <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

> I hope I am  not understanding correctly.     IETF is supposed to be looking ahead to provide better answers and circumvent predictable problems.    Not ignoring,  waiting and then reacting to nega…

What exactly is the problem you are concerned with? As I've pointed out previously one can still log the contents of TLS protected
connections: you do this at the client, or with an intercepting proxy.
What information does this not get you that you need on the network?

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 17:02:06 +0000 (UTC)

>>
>> What I am saying,  in relation to your "Delivering a stable product"  comment is that over time various industries have learned what it takes to "Deliver a stable product".    We did not >>want to invest millions in these debugging networks.  But  we learned the hard way,  that it was necessary.
>> I am not a member of the banking coalition that started this subject,  nor of the banking industry at all,  but I certainly understand their perspective and am concerned about  the same >>unmanageable future they described.

>Do  Akami, Cloudlflare and Google magically not have these problems?
It would be very interesting to get the network diagnostic and operations people (rather than the architects) of the above companies involved in this conversation.
Also, you know, companies don't really enjoy spending money on network diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so.   
Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).
Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.
Nalini

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Sep 2016 10:37:43 -0700

A few observations:

+ TLS 1.3 is designed around the assumption that we are doing DH-style
  key establishment. There are good reasons for this, both in terms of
  protocol simplicity and in terms of establishing a baseline of
  strong modes (PFS, compatibility with standard uses of EC,
  etc.). Re-adding a key transport mode like TLS 1.2 static RSA would
  be extremely disruptive, even if it weren't being raised so late in
  the process. It's certainly not just a matter of changing some
  RFC 2119 language forbidding static RSA.

+ As several people have observed, there are several potential ways to
  build an equivalent capability that's compatible with TLS 1.3 as it
  currently is designed (see for instance Hugo Krawczyk's email [0])
  They would of course require a different interface between the
  monitoring appliance and the server (i.e., you would need to export
  a different kind of key and use it somewhat differently on the
  monitoring system), but it's not significantly less efficient.

-Ekr

[0] As well as his caveat about analysis being needed here.

On Fri, Sep 23, 2016 at 9:49 AM, Ackermann, Michael <[email-masked]>
wrote:

> Without re stating the original message from the bank coalition,  which
> states this better than I could,   the client and MITM solutions are not
> practical in many situations.    Also they do not provide the scope, depth
> or detail that is utilized with today's solutions.
>
> > Is it that we should create or even allow an environment to develop,
> where all providers of service cannot  provide effective diagnostics and
> support?   And then see the constituents of these industries collapse
> together.     And only then realize we have an issue?
> > I hope I am  not understanding correctly.     IETF is supposed to be
> looking ahead to provide better answers and circumvent predictable
> problems.    Not ignoring,  waiting and then reacting to negative
> situations that can and should be avoided.
>
> What exactly is the problem you are concerned with? As I've pointed out
> previously one can still log the contents of TLS protected
> > What I am saying,  in relation to your "Delivering a stable product"
> comment is that over time various industries have learned what it takes to
> "Deliver a stable product".    We did not want to invest millions in these
> debugging networks.   But  we learned the hard way,  that it was necessary.
> > I am not a member of the banking coalition that started this subject,
> nor of the banking industry at all,  but I certainly understand their
> perspective and am concerned about  the same unmanageable future they
> described.
>
> >> From the perspective an Enterprise that runs these applications and has
> invested HEAVILY in the debugging networks.........
> >>
> >> The reason we are debugging these networks is so that "The 5-6 order of
> magnitude of folks using them"  will have good service.   If they do not,
> they will consider competitors and/or generate a litany service calls or
> complaints.        I.E.     When these "Folks"  are slow or not working
> they are just as unhappy as we are.
> >>
> >
> > Isn't that the market operating as expected? Those who deliver a stable
> product at a competitive price are rewarded, while those who fail to
> deliver or deliver at an unreasonable cost are not? (Some hand waiving).
> >
> then it might indicate a major course correction is needed. But I don't
> think that's the case here.
> >
> > Jeff
> >
> >
> > The information contained in this communication is highly confidential
> and is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue Cross and
> Blue Shield Association.
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 23 Sep 2016 19:08:18 +0000

> It would be very interesting to get the network diagnostic and operations people (rather than the architects) of the above companies involved in this conversation.

Nothing has ever stopped them.  Never. Participation is as simple as joining a mailing list.  The IETF has been doing SSL and TLS for nearly 20 years.  It is not a secret.  It was incumbent on them to reach out and get involved.   

> Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have pr…

Don't try to equate "listen to each other" with "meet my requirement."  The message has been stated, very clearly, from individuals, WG members, through document editors and WG chairs and up to Security Directors:  static RSA is not coming back to TLS 1.3 .  Since before the last IETF this was the message, consistently.  So perhaps you should answer the question first -- why aren't *you* listening? :)

PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to prevent PFS in their existing deployment?  Why won't additional controls to prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So far all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to move to TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs in TLS 1.3 too.

Look, pretty much the entire world is being spied on by national-scale adversaries who are recording all traffic for eventual decryption and correlation.  *Almost everyone* is having their traffic surveilled. The problems of debugging a set of enterprise apps doesn’t amount to a hill of beans in that world. It just doesn't. Same for a particular industry's regulatory requirements. 

> Isn't our goal to have the best standards possible?   Any organism (including the IETF), needs feedback to thrive.

Oxygen, coke, and cookies too.

---

From: BITS Security <[email-masked]>
Date: Fri, 23 Sep 2016 19:31:44 +0000

> What information does this not get you that you need on the network?

For enterprises using Content Delivery Networks, the TLS session from the browser ends at the edge server in the Content Delivery Network.  The session that the enterprise sees is completely different: different IP's and ports, different TLS session, different application layer content because of caching, different network behavior (like packet drops and retransmissions).  If some infrastructure component in the data center is causing a problem, a trace on the browser side is blind to that.  An additional problem is that Microsoft does not allow logging of ephemeral keys in their browser. 

Likewise endpoint logging in the data center often does not provide adequate data to isolate the fault domain and/or the root cause of a problem.  Logs tell you that an event happened but not why it happened or which infrastructure component was the cause of the problem. For example, a log may indicate that a call was made that either didn't get answered or received a slow answer, but there could be ten infrastructure components between the server that made the call and the destination server that is supposed to answer.   

>From the time a packet enters a data center, it is travelling through routers, switches, firewalls, load balancers, web servers, app servers, middleware servers, and possibly hitting a mainframe, all TLS encrypted for many enterprises.  Frequently, source and destination IP's are NAT'ed multiple times, so there is no visible relationship between the packet that enters the data center and the same call at deeper layers of the infrastructure.  Any one of these infrastructure nodes could be the cause of a problem.  The way to isolate the fault domain of a problem is to take a packet trace at each tier of the application infrastructure and look at the application layer data in a decrypted trace in order to find the transaction that is failing. 

Large enterprises have built up robust out-of-band packet capture infrastructures in order to provide better network and application layer visibility than what logs provide.  Packet brokers and sniffers can handle 10 Gbits/sec. line rate or more of traffic, including write to disk at 20 Gbits/sec. or more.  This is needed because when IP's are NAT'ed, you have to trace everything in and out of a particular server and then decrypt in order to find the transaction of interest.  Some endpoints and/or infrastructure components have packet capture capability, but most are not robust enough to handle this kind of packet capture load in a busy production environment. 

There can be twenty or more layers to a large application, all TLS encrypted, that need to be inspected for troubleshooting, and replacing this with MITM infrastructure is not scalable.  Likewise, there can be hundreds of physical network taps feeding security monitoring tools like IDS/IPS, malware detection, and fraud monitoring.  Threats are coming not just from the Internet, but also from internal or 3rd party machines that have been compromised and then start reconnaissance from a wide variety of locations.  Large enterprises also have complex virtual environments which can be running TLS between VM's.  There is no scalable way to intercept VM to VM TLS that never leaves the virtual server.

--Andrew

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 23 Sep 2016 15:37:05 -0400

> Look, pretty much the entire world is being spied on by national-scale adversaries who are recording all traffic for eventual decryption and correlation.  *Almost everyone* is having their traffic…

+1, this and what follows is why its important to me.

Years ago I worked with a Vietnamese fellow named Say Ok. We had a
shared locker room, and I noticed Say had six or eight scars on his
chest and abdomen, so I asked what they were. They were the scars from
the bullet holes when the North Vietnamese tried to murder him because
he wanted a democracy and better life for his children.

I can't even talk about some of the obscene things I know are going on
in some US DoD programs. I'm hoping/waiting for Glenn Greenwald, Laura
Poitras and Ewen MacAskill to break those stories.

Jeff

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 23 Sep 2016 22:51:45 +0300

>> connections: you do this at the client, or with an intercepting
>> proxy. What information does this not get you that you need on the
>> network?
>
> For enterprises using Content Delivery Networks, the TLS session from
> the browser ends at the edge server in the Content Delivery Network.
> The session that the enterprise sees is completely different:
> different IP's and ports, different TLS session, different
> application layer content because of caching, different network
> behavior (like packet drops and retransmissions).  If some
> infrastructure component in the data center is causing a problem, a
> trace on the browser side is blind to that.  An additional problem is
> that Microsoft does not allow logging of ephemeral keys in their
> browser.
>
[...]
>> From the time a packet enters a data center, it is travelling
>> through routers, switches, firewalls, load balancers, web servers,
>> app servers, middleware servers, and possibly hitting a mainframe,
>> all TLS encrypted for many enterprises.  Frequently, source and
>> destination IP's are NAT'ed multiple times, so there is no visible
>> relationship between the packet that enters the data center and the
>> same call at deeper layers of the infrastructure.  Any one of these
>> infrastructure nodes could be the cause of a problem.  The way to
>> isolate the fault domain of a problem is to take a packet trace at
>> each tier of the application infrastructure and look at the
>> application layer data in a decrypted trace in order to find the
>> transaction that is failing.
>

You are implicitly suggesting to remove perfect-forward-secrecy as soon 
as a TLS flow is created by the CDN. However these packets will still be 
traveling over the public Internet and/or "private" (leased, not really 
private) MPLS VPNs, where we KNOW that government agencies are 
eavesdropping and recording network flows to keep for years ahead. In 
other words, even when the TLS flow enters "your" network, you and your 
customer are still at risk from pervasive monitoring.

Thanks,
	Yaron

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 23 Sep 2016 13:14:42 -0700

I work in the payments industry, but I am not speaking on behalf of my
employer.

I would like to note that if the approaches outlined in the "BITS Security"
post are the preferred ones for the companies they represent, those
companies have made a huge strategic blunder and should correct those
strategic blunders rather than requiring last-minute major design overhauls
to TLS 1.3 which would weaken its security.

+1000 Kenny Patterson's comments.

> threat vector is the possessor of the endpoint.

I strongly disagree. 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 don't have
endpoint security, all is lost. I would suggest performing multiple
security checks regularly on all endpoints throughout your enterprise.

Modern endpoint agents can work at a level much higher than TLS network
packets (i.e. total memory inspection with kernel-level agents). MitMing
traffic in lieu of deploying an endpoint agent only provides monitoring of
"compliant" packet streams, which are unlikely to be used by either
attackers or insider threats. I'm not saying it's bad to run NIDS or a
rolling packet capture system, these are both great, but again, neither are
a replacement for an endpoint agent.

> adopted into the standard by the TLS 1.3 Working Group.

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. As a general recommendation, I would suggest building out
debugging facilities for your payment stack so you know it actually works,
and don't have to lean on crutches like MitMing traffic for debugging
purposes.

While such a crutch may in the short-term make debugging appear easier, it
also assists a patient attacker with internal network access who is
passively capturing traffic before attempting to obtain a decryption key
which would expose payment credentials e.g. cardholder info/PANs, ACH
account numbers, etc.

tl;dr: your suggestions would harm the security of more "forward thinking"
payments companies. Again, my personal opinion, not that of my employer.

-- 
Tony Arcieri

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 23 Sep 2016 23:24:24 +0300

On Thu, Sep 22, 2016 at 05:19:48PM +0000, BITS Security wrote:
> problems for financial institutions, almost all of whom are running
> TLS internally and have significant, security-critical investments in

It is not merely deprecated, the whole TLS 1.3 design assumes DH-like
key exchange, which RSA key exchange isn't. It has been this way from
the earliest designs, which were over 2 years ago.

If you are thinking you can have static RSA key exchange in TLS 1.3, you
are just plain wasting your time. There will not be static RSA in TLS
1.3. No matter how much "inconvience" you claim that causes.

Also, security protocol design is hard enough without backdoors. Try to
add those and everything will just come apart. In way that lets the "bad
guys" (however you define those) to waltz in.

-Ilari

---

From: BITS Security <[email-masked]>
Date: Fri, 23 Sep 2016 20:31:10 +0000

Rich (et al.) -- I understand where you are coming from but I will poke a little bit at this portrayal.  

We are not here hat-in-hand asking for a return to RSA key exchange to the proposed standard.  We do however want to raise our concern (and hopefully your awareness) of what appears to be an unintended consequence of the move to PFS-only choices.  

What is happening from our perspective is choice is being removed and an adequate replacement has (seemingly) not been identified.  This lack of choice may not affect everyone and every use-case but it will predictably affect large, complex, highly regulated enterprises in a serious manner.  This is a classic case of security requirement being in conflict with a different security requirement.  

IETF protocols are run extensively both on the public Internet and within private enterprises.  Any decisions made by the TLS Working Group will affect both environments, and the needs and requirements of both environments should be considered.

-Andrew

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz _______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Fri, 23 Sep 2016 23:40:22 +0300

> On 23 Sep 2016, at 10:08 PM, Salz, Rich <[email-masked]> wrote:
> 
> 

+1

And if almost everyone is having the traffic surveilled, you can bet that the financial industry in every country is definitely being surveilled. Probably by multiple agencies from multiple countries.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Sep 2016 13:43:15 -0700

Andrew,

What would probably be most helpful here would be if you tried to describe
what you think your requirements are in some sort of protocol-neutral
fashion.

-Ekr

On Fri, Sep 23, 2016 at 1:31 PM, BITS Security <
[email-masked]> wrote:

> We are not here hat-in-hand asking for a return to RSA key exchange to the
> proposed standard.  We do however want to raise our concern (and hopefully
> your awareness) of what appears to be an unintended consequence of the move
> to PFS-only choices.
>
> What is happening from our perspective is choice is being removed and an
> adequate replacement has (seemingly) not been identified.  This lack of
> choice may not affect everyone and every use-case but it will predictably
> affect large, complex, highly regulated enterprises in a serious manner.
> This is a classic case of security requirement being in conflict with a
> different security requirement.
>
> IETF protocols are run extensively both on the public Internet and within
> private enterprises.  Any decisions made by the TLS Working Group will
> affect both environments, and the needs and requirements of both
> environments should be considered.
>
> -Andrew
>
>
> > It would be very interesting to get the network diagnostic and
> operations people (rather than the architects) of the above companies
> involved in this conversation.
>
> Nothing has ever stopped them.  Never. Participation is as simple as
> joining a mailing list.  The IETF has been doing SSL and TLS for nearly 20
> years.  It is not a secret.  It was incumbent on them to reach out and get
> involved.
>
> > Why don't we listen to each other?   I know at IETF, I often hear that
> we don't get enough operators to comment and give feedback.  Well, here you
> have some.  It may be that these companies have problems that are different
> from Google's (just as an example).
>
> Don't try to equate "listen to each other" with "meet my requirement."
> The message has been stated, very clearly, from individuals, WG members,
> through document editors and WG chairs and up to Security Directors:
> static RSA is not coming back to TLS 1.3 .  Since before the last IETF this
> was the message, consistently.  So perhaps you should answer the question
> first -- why aren't *you* listening? :)
>
> PFS is also possible in TLS 1.1 and later.  What does, say USBank, do to
> prevent PFS in their existing deployment?  Why won't additional controls to
> prevent TLS 1.3 and its mandatory PFS be expected to work here as well?  So
> far all I've seen is "maybe there's bugs in TLS 1.2 and we'll be forced to
> move to TLS 1.3"  Shrug.  There are bugs everywhere.   Maybe there's bugs
> in TLS 1.3 too.
>
> Look, pretty much the entire world is being spied on by national-scale
> adversaries who are recording all traffic for eventual decryption and
> correlation.  *Almost everyone* is having their traffic surveilled. The
> problems of debugging a set of enterprise apps doesn’t amount to a hill of
> beans in that world. It just doesn't. Same for a particular industry's
> regulatory requirements.
>
> > Isn't our goal to have the best standards possible?   Any organism
> (including the IETF), needs feedback to thrive.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 23 Sep 2016 20:52:40 +0000

> adequate replacement has (seemingly) not been identified.

So far I've seen two alternatives mentioned.  Monitor at the endpoint, and use TLS 1.2.  (You already have the PFS issue with TLS 1.1 and beyond).

Not everything the IETF does will drop seamlessly into all enterprise deployments.  But hey, at least you're not running SNA networks any more :)
--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Xiaoyin Liu <[email-masked]>
Date: Fri, 23 Sep 2016 20:59:59 +0000

Andrew,

I don’t understand why your “choice is being removed”, because you can keep using TLS1.2 in your internal network, can’t you?

Best,

Xiaoyin

From: BITS Security<mailto:[email-masked]>
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

-Andrew

---

From: BITS Security <[email-masked]>
Date: Fri, 23 Sep 2016 21:10:31 +0000

It's possible to run TLS 1.3 and PFS through the Content Delivery Network and into the enterprise data center, and then have a load balancer or other proxy terminate TLS.  This gives us the option of running a different protocol in the data center, but we need a better option than TLS 1.2 that will, perhaps sooner than we might expect, be deprecated.  

-Andrew 

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 3:52 PM
To: BITS Security <[email-masked]>; Watson Ladd <[email-masked]>; Ackermann, Michael <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

You are implicitly suggesting to remove perfect-forward-secrecy as soon as a TLS flow is created by the CDN. However these packets will still be traveling over the public Internet and/or "private" (leased, not really
private) MPLS VPNs, where we KNOW that government agencies are eavesdropping and recording network flows to keep for years ahead. In other words, even when the TLS flow enters "your" network, you and your customer are still at risk from pervasive monitoring.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Sep 2016 22:21:03 +0100

Andrew,

On 23/09/16 21:31, BITS Security wrote:
> We do however want to raise our concern (and hopefully your
> awareness) of what appears to be an unintended consequence of the
> move to PFS-only choices.

I don't believe I've heard anything in this discussion so far
that wasn't well-known and discussed when the WG decided to
remove static RSA key transport a couple of years ago but I've
not gone back and checked the list archive and meeting minutes.

Given what you say above, am I right in assuming that you
yourself went back and reviewed those in order to reach the
conclusion that these are unintended consequences and not just
the result of a well-considered analysis? If so, can you say
exactly what was not considered before? If not, then maybe
you could consult the archive and minutes, as that's the usual
expectation in the IETF.

S.

---

From: BITS Security <[email-masked]>
Date: Fri, 23 Sep 2016 21:24:42 +0000

> providers will be happy to implement whatever you need in the way of

The issue here is not just collaboration applications; it’s also point-to-point messaging protocols.   
  
Some vendors have created p2p messaging services to meet supervision requirements, and these have an explicit man-in-the-middle.   
  
But general-purpose messaging services (and other collaboration services) which don’t have an explicit man-in-the-middle (and don’t permit server-side access to user plaintext and can’t be observed by other means) can’t be used in supervised environments. This rules out many cloud-hosted services today. 
  
In the future, even enterprise-hosted versions of messaging services probably won’t be usable in supervised environments if there’s no way for the enterprise to access traffic except on the destination endpoint.   

> comes to circumventing monitoring? 

The issue isn’t getting people to behave, or punishing them when they don’t; it’s demonstrating that the business has met its legal obligation to create a record of communications that can be accessed in case of an investigation.  An employee who circumvents controls can be fired, but that does not absolve the business of liability for failing to create a legally required record of the content of that employee’s communications.

- Andrew

-----Original Message-----
From: Watson Ladd [mailto:[email-masked]] 
Sent: Thursday, September 22, 2016 3:06 PM
To: BITS Security <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

You've "recently learned" about a change that was proposed several
*years* ago, starting in the earliest drafts of TLS 1.3. This change is being made due to substantial security issues with encryption based key exchanges: while we could redesign the exchange to repair these issues, the risk of key compromise resulting in decryption of old data is real.

> 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 tha…

Let's get specific about how this works: if an employee of a regulated institution is logging into a TLS protected social media website, how do you decrypt the connection without using a MITM device on the network? I'm sure with large enough checks collaboration application providers will be happy to implement whatever you need in the way of logging at the server.

> 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 transac…

This can be solved by logging the entire connection contents at the endpoint. I don't understand how you say that this is not a
replacement: it's literally the same data as you obtain decrypting the session. This is a requirement that many of the companies involved in the TLS 1.3 process have also, and they haven't complained about it.
Maybe I don't understand what architecture you have which makes this impossible. If you have too much volume, then I don't see how your network appliance doesn't have the same problem. If it's intermittent, and you didn't log verbosely on errors, set up the endpoint to log the next fault, and wait.

> 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 instit…

Browsers haven't even succeeded in killing SSL 3.0 yet. I think you have much more time then you think to stay on TLS 1.2.

> -  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 monito…

And firing isn't enough of a threat to get people to behave when it comes to circumventing monitoring?

> 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,…

Critical to whom? Not me. If you want to propose a solution that works please do so. But don't pretend your problems are our problems.

Sincerely,
Watson Ladd

---

From: Watson Ladd <[email-masked]>
Date: Fri, 23 Sep 2016 14:28:36 -0700

> Likewise endpoint logging in the data center often does not provide adequate data to isolate the fault domain and/or the root cause of a problem.  Logs tell you that an event happened but not why i…

I think you are confused about endpoints. Either these middleboxes
terminate a TLS connection or they do not. If they do, you can log the
application layer traffic at that box in and out. If they do not, then
IP level captures tell you what they are doing.  That some of these
endpoints are middleboxes from the standpoint of a higher layer of the
stack doesn't change that they are endpoints from the TLS layer's
perspective. I don't see what the barrier is.

> From the time a packet enters a data center, it is travelling through routers, switches, firewalls, load balancers, web servers, app servers, middleware servers, and possibly hitting a mainframe, a…

I do not want to be the person who has to figure out which SQL query
came from which HTTP request. Much easier to have the webserver tell
me (and maybe even add standard headers to permit RPC tracebacks).
Even better is it can track only those ensuing requests that
ultimately result in a failure.

> Large enterprises have built up robust out-of-band packet capture infrastructures in order to provide better network and application layer visibility than what logs provide.  Packet brokers and sni…

You do not need to capture every exchange, just the interesting ones.
What this sounds like is an environment where you have deployed dozens
of boxes with fast stripes on the side, with no real ability to ensure
that they are able to properly log, or administrative insight into
what black magic they might be doing, and have tried to make up with
it with dirty, labor-intensive hacks.

> There can be twenty or more layers to a large application, all TLS encrypted, that need to be inspected for troubleshooting, and replacing this with MITM infrastructure is not scalable.  Likewise,…

The word scalable has a meaning. MITM scales linearly.

---

From: BITS Security <[email-masked]>
Date: Fri, 23 Sep 2016 21:34:55 +0000

> you can keep using TLS1.2 in your internal network, can't you?

There are both public and private sector regulators arcing towards being more prescriptive in this area.  It is possible, if not likely, in the not too distant future that my member companies will not have the choice to "downgrade" to "obsolete" TLS versions.  

Note: the standards track document says it "Obsoletes: RFC 5246" which is TLS 1.2.  That's a signal that may prove difficult to divert in this rapidly evolving threat and regulatory environment.

- Andrew 

From: Xiaoyin Liu [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 5:00 PM
To: BITS Security <[email-masked]>; Salz, Rich <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Andrew,
 
I don't understand why your "choice is being removed", because you can keep using TLS1.2 in your internal network, can't you?
 
Best,
Xiaoyin
 
From: BITS Security
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich; [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

-Andrew

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Look, pretty much the entire world is being spied on by national-scale adversaries who are recording all traffic for eventual decryption and correlation.  *Almost everyone* is having their traffic surveilled. The problems of debugging a set of enterprise apps doesn't amount to a hill of beans in that world. It just doesn't. Same for a particular industry's regulatory requirements.

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 23 Sep 2016 17:44:47 -0400

> There are both public and private sector regulators arcing towards being more prescriptive in this area.  It is possible, if not likely, in the not too distant future that my member companies will…

Its not the first time C&A has worked against security.

Password complexity and rotation policies come to mind; they cause the
security in the system to drop as users are forced to comply.

Would a KMIP/KeyServer help? Hosts can ask the key server server for
its random key or seed material, and then use them key derivation and
for protocol execution. I built a proof of concept interception proxy
to do it a few years ago to help understand the intersection a service
like CipherCloud with C&A.

Jeff

---

From: Adam Caudill <[email-masked]>
Date: Fri, 23 Sep 2016 18:19:18 -0400

Andrew,

You are requesting a major design change at the last minute, to restore a problematic feature that was removed due to its negative security impact. You should understand from the beginning that this is an extreme request. Moreso, you should understand that others in your industry have no problem complying with US and international regulations, while using PFS cipher suites.

I am personally aware of two of the largest financial organizations in the US that actually require PFS suites for all internal and external applications, and use endpoint security applications to handle this issue. It may not be as convenient as what you are doing now, but it is a problem that has already been solved, and solved effectively.

Before claiming that the IETF is eliminating your choice, you may want to take a closer look at how those your industry have already dealt with this. There are effective solutions that have already been mentioned, that don’t involve reducing the security of every TLS user around the globe.

Personally, I agree completely with Kenny’s response - the answer is simply no. It’s too large of a change, it has too large of a security impact, and there are established solutions to address your issues.

--
Adam Caudill
[email-masked]
http://adamcaudill.com/

> On Sep 23, 2016, at 5:34 PM, BITS Security <[email-masked]> wrote:
>

---

From: Peter Bowen <[email-masked]>
Date: Fri, 23 Sep 2016 16:17:35 -0700

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security
<[email-masked]> wrote:
>  we need a better option than TLS 1.2 that will, perhaps sooner than we might expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange
versus DH for key exchange would only seem to apply when the network
tapping system has access to the RSA key, right?  So the part of this
about monitoring the network for external chat and such doesn't really
change if the client is using TLS 1.1 or 1.3, as you still can't
decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat
under control of the monitor, so it can support TLS 1.2 as long as
needed.  TLS 1.0 came out in 1999 and is still now (in 2016) widely
deployed.  While I hope TLS 1.3 deployment is speedy, I don't forsee
browsers dropping TLS 1.2 and earlier support any time soon.

Thanks,
Peter

---

From: Bill Frantz <[email-masked]>
Date: Fri, 23 Sep 2016 18:30:38 -0700

On 9/23/16 at 2:24 PM, [email-masked] (BITS 
Security) wrote:

>But general-purpose messaging services (and other collaboration 
>services) which don’t have an explicit man-in-the-middle (and 
>don’t permit server-side access to user plaintext and can’t 
>be observed by other means) can’t be used in supervised 
>environments. This rules out many cloud-hosted services today.

I see a train wreck coming and it looks like this:

The public internet, Google, Cloud services, Facebook, Twitter, 
etc. etc. move in the direction of improving security using 
things like PFS, because the idea of protecting human rights 
advocates in the parts of the world where people are routinely 
tortured sells well to the general public, people like me, and 
others on this list.

On the other hand, some major enterprises continue to depend on 
being able to break the security of their employees to monitor 
their networks in ways that the bad guys can easily use, as 
opposed to installing endpoint or gateway monitoring.

This train wreck results in fewer and fewer public internet 
services being available to users within these enterprises. 
Eventually, employees give up on the corporate network and start 
using their cell phones to communicate with customers, research 
investments etc., completely bypassing the regulatory required monitoring.

This scenario says it doesn't matter whether TLS 1.3 and 
successors allows RSA. If they have any PFS modes, these will be 
the only ones public internet servers will accept. If they are 
turned off in enterprise clients, they will not be able to 
connect without going through a gateway which turns them on.

My conclusion is that enterprises that depend on being able to 
decrypt traffic without involving the endpoints should start 
moving to systems that do involve the endpoints.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506      | contact sport.               | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, 
CA 95032

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 24 Sep 2016 02:44:50 +0000

> we need a better option than TLS 1.2 that will,
> perhaps sooner than we might expect, be deprecated.

Why?

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 24 Sep 2016 02:50:58 +0000

> There are both public and private sector regulators arcing towards being
> more prescriptive in this area.  It is possible, if not likely, in the not too distant
> future that my member companies will not have the choice to "downgrade"
> to "obsolete" TLS versions.
> 
> Note: the standards track document says it "Obsoletes: RFC 5246" which is
> TLS 1.2.  That's a signal that may prove difficult to divert in this rapidly
> evolving threat and regulatory environment.

Then the industry will have to explain to its regulators that the latest version of the standard prevents them from doing what is required, in the way that it was, apparently, traditionally done.  You can intercept and monitor TLS 1.3, but it mus be done at one of the endpoints, not via a passive intermediary watch traffic.   We removed that capability because of the threat of national-scale actors doing such things on a global basis.

---

From: Pawel Jakub Dawidek <[email-masked]>
Date: Fri, 23 Sep 2016 23:54:11 -0700

Hello.

As a vendor of one of those MITM proxy solutions for TLS inspection I'd
be grateful if you could be more specific about the "scope, depth and
detail" that is not delivered by such solutions, so we can have
discussion whether this is something we can address or not and if not,
maybe we can come up with some alternative solutions before we give up.

By doing MITM we increase latency, even if very little, that's
inevitable. But can you really avoid doing MITM TLS inspection?
In my opinion, no. Let me elaborate.

Of course the amount of TLS traffic is growing rapidly (which is a good
thing) thanks to many "contributions":
- Server Name Indication extenstion,
- Edward Snowden,
- Free certificates (eg. Let's Encrypt),
- HTTP 2.0.

Because of that, every corporate network needs visibility inside TLS
traffic not only incoming, but also outgoing, so they can not only
debug, but also look for data leaks, malware, etc.

Customers are increasingly aware of all this and it is not a question of
MITM incresing latency, because it has to be done, the more important is
to make it in a decrypt-once-feed-many fashion, as they have multiple
solutions in place to analyze the traffic for different reasons.

And when you do data leak prevention or malware detection you want to be
in the middle so you can terminate the session as quickly as possible.

I don't want to say that Forward Secrecy comes at no price. It makes
observabilty harder (not impossible), it has higher CPU demands, it
increases handshake times. This is the price we pay for a better
security and in my opinion it is acceptable.

-- 
Pawel Jakub Dawidek
Chief Technology Officer
Wheel Systems / http://www.wheelsystems.com

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 24 Sep 2016 19:22:46 +0000

What I mean is that we have Many MITM solutions today and they are able to be a good source for troubleshooting/diagnostics, in limited situations or perspectives.    This lack of scope, depth and detail are what drove us to install the packet collection infrastructures (debugging networks I think some are saying).    

Some of the issues we have found include: 
* Level of detail is not sufficient.
* Inherent tools are not sophisticated.  
* Data is difficult to share.   
* MITM management systems frequently do not "Play well" with overall management frameworks and other tools.  
* Problems take longer to resolve.  
* Depending upon the level of information logged on an MITM platform,  the inherent  processing can (and frequently does), create performance problems on the MITM and can change conditions,  obfuscating the original issue. 
* MITMs are not usually configured to record, retain, archive or manage large amounts of diagnostic data.  
* A MITM platform frequently has a very limited vision of the overall session path.   Or,  there may be multiple MITM's involved in a session path.    Which one has the best view?  Which one(s) should you focus on?  
* AND,  as you said,  the more MITMs you add, the more latency and complexity you are forced to deal with.    As a network diagnostic person this approach can actually make your responsibilities more difficult and  less achievable. 
* The information collected is usually not granular enough to perform network diagnostics for those situations that require it. 
* One key initial piece of information in troubleshooting is to determine if the source of the problem is in: the Client, the Network or the Server.   MITM's are rarely able to provide insight into this critical and time sensitive determination.  
* in general diagnostics are made more difficult with this approach.  Multiple sessions and possibly interfaces may need to be traced and the MITM can further confuse things by acting as a router and/or a nat and/or a Load Balancer.   As someone who deals with these types of additional complexities every day,  I would like to see fewer MITMs  rather than more.      

My organization uses the MITM diagnostics and management systems, and like most point solutions they are a valuable facet of our diagnostic arsenal,  but because of the manifold shortcomings (some of which are listed above),  they are not a central focus and are not a viable initial focal point or  suitable overall point of triage.     Triage may dictate the use of the MITM diagnostics,  but MITM troubleshooting/diagnostics would not be an effective method on its own,  for most situations/issues that exist in today's complex multi-tier applications.  

My job is to make things work and fix them ASAP when they don't.   While I fully understand the need for effective security,  I hope those on the security side  would conversely understand the need to make things work, perform well,  and quickly diagnose problems when they do not.      I am often reminded of a colleague who states (jokingly I think)   "The ultimate security is where no data flows and nothing works".     I hope this is not the direction we are heading and that some form of compromise will be forthcoming between these two discrete factions with differing perspectives.  

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Pawel Jakub Dawidek
Sent: Saturday, September 24, 2016 2:54 AM
To: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Hello.

As a vendor of one of those MITM proxy solutions for TLS inspection I'd be grateful if you could be more specific about the "scope, depth and detail" that is not delivered by such solutions, so we can have discussion whether this is something we can address or not and if not, maybe we can come up with some alternative solutions before we give up.

By doing MITM we increase latency, even if very little, that's inevitable. But can you really avoid doing MITM TLS inspection?
In my opinion, no. Let me elaborate.

Because of that, every corporate network needs visibility inside TLS traffic not only incoming, but also outgoing, so they can not only debug, but also look for data leaks, malware, etc.

Customers are increasingly aware of all this and it is not a question of MITM incresing latency, because it has to be done, the more important is to make it in a decrypt-once-feed-many fashion, as they have multiple solutions in place to analyze the traffic for different reasons.

And when you do data leak prevention or malware detection you want to be in the middle so you can terminate the session as quickly as possible.

I don't want to say that Forward Secrecy comes at no price. It makes observabilty harder (not impossible), it has higher CPU demands, it increases handshake times. This is the price we pay for a better security and in my opinion it is acceptable.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 25 Sep 2016 00:45:19 +0300

On Thu, Sep 22, 2016 at 03:29:42PM -0400, Dave Garrett wrote:
> 
> Yes, all of these other channels are protected using TLS... which you
> do not control in any way. Also, many sites/services already prioritize
> FS cipher suites, so the deprecation of plain RSA key exchange doesn't
> actually affect the vast majority of people. (e.g. Facebook & Twitter
> both prefer ECDHE with NIST P-256) Within this very argument is
> already the argument that supervision at endpoints is required here.
> he security on the pipe is irrelevant. I don't see how you can make a
> point to bring this up but think keeping plain RSA KE suites is a
> useful solution.

Well, if you have client and server that both have RSA KE enabled
(even if not preferred), you can do something like this:

- Intercept ClientHello. Strip any FPS ciphersuites and any associated
  extensions, strip EMS and ALPN but keep client_version and
  client_random the same.
- The server will select RSA KE.
- Intercept Certificate message and replace it with MITM cert.
- Intercept ClientKeyExchange decrypt the key and re-encrypt with the
  original server key.
- Compute the session key and log it.
- Intercept the ClientFinished message and replace it with fixed
  version.
- Intercept the ServerFinished message and replace it with fixed
  version.
- Get off the active path, becoming passive.
- Log the data transfer on the connection, and later decrypt it if
  desired.

The keys will match, because they only depend on randoms (which
were preserved) and the encrypted secret (which was preserved too).
The EMS was stripped because it would break this.

The MITM proxy knows the secrets needed to fix the Finished messages.

Preferring FS won't help, because MITM proxy can downgrade the
crypto negotiation.

(And it is not like one can easily get the keys without either
replacing the cert or knowing the RSA private key corresponding to
it).

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 25 Sep 2016 02:09:47 +0000

>   This lack of scope, depth and detail [in MITM infrastructures] are what drove us to
> install the packet collection infrastructures (debugging networks I think some
> are saying).

At the risk of repeating myself and flogging this dead horse...  What you are doing is exactly what the nation-state actors are doing.  I bet that some even use that exact phrase of "packet collection infrastructure." 

I understand that if you want to use TLS 1.3, it is going to be expensive and/or inconvenient; you're going to have to educate regulators and get bespoke TLS endpoint solutions from vendors. Perhaps you can get the NSA's to stop collecting everyone's Internet traffic for future decoding?

Less flippantly, what specifically would you have us do? What do you want in the protocol that enables your needs, but doesn't make it possible for everyone in the world to be surveilled?  Please, make some specific suggestions.

---

From: Brian Sniffen <[email-masked]>
Date: Sat, 24 Sep 2016 23:31:22 -0400

[email-masked] writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>

Hi, technical person most directly responsible for incident response and
urgent debugging here.  We modify endpoints to get what we need.  We did
have taps that relied on knowing the RSA Kx secret... but haven't used
them in about a decade.

I think the banks have an answer not available to the global passive
adversaries: modify the server or client to use a fixed ECDH share, then
use tech much like their current choices.  It'll take a while to
develop, but nobody in that environment plans to move to TLS 1.3 for
operational systems any time soon anyway.

-Brian

-- 
Brian Sniffen
Akamai Technologies

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sun, 25 Sep 2016 21:20:04 +0000

I understand your concern over what the nation-state actors are doing but it is not the same as what Enterprises do to manage their private servers, networks and clients.        
 
Your final paragraph is quite a constructive question.   "What specifically would you have us do? What do you want in the protocol that enables your needs, but doesn't make it possible for everyone in the world to be surveilled?  Please, make some specific suggestions."

My personal perspective would be, that the approach to achieving an answer to that important question, would start with:

1.  Gathering  protocol neutral requirements from all involved factions,  (with help and suggestions from people on the TLS list)

2.   Brainstorming session(s) with people on the TLS list as well potential users/operators, with objectives that include the design of a solution that meets (hopefully) all known requirements.  

What I would like to see come out of the debate we seem to be currently involved in,  is the realization that significant operational/management  issues exist with TLS 1.3 and that the IETF is taking them seriously enough to at least begin dialogue intended to address these issues, and potentially work together to craft related solution(s).   In my view this issue is far too complex &  pervasive to believe that any one person or group's perspective would produce a viable overall solution.  

Again, let me restate,  I don't think anyone is saying that we MUST have RSA.    But, we, as the clients of the IETF TLS protocol, would like to work with you to assure we have workable, manageable  and affordable solutions,  that meets our needs as well as the needs of others.

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]] 
Sent: Saturday, September 24, 2016 10:10 PM
To: Ackermann, Michael <[email-masked]>; Pawel Jakub Dawidek <[email-masked]>; [email-masked]
Subject: RE: [TLS] Industry Concerns about TLS 1.3

>   This lack of scope, depth and detail [in MITM infrastructures] are 
> what drove us to install the packet collection infrastructures 
> (debugging networks I think some are saying).

---

From: Watson Ladd <[email-masked]>
Date: Sun, 25 Sep 2016 14:34:59 -0700

> I understand your concern over what the nation-state actors are doing but it is not the same as what Enterprises do to manage their private servers, networks and clients.

It totally is. You record the traces, then use the private key to
decrypt them. The packets are stupid, they don't know the difference!

> 1.  Gathering  protocol neutral requirements from all involved factions,  (with help and suggestions from people on the TLS list)

You know, you could have made those requirements known to us in this
email. How many months extra do you want us to take?

> 2.   Brainstorming session(s) with people on the TLS list as well potential users/operators, with objectives that include the design of a solution that meets (hopefully) all known requirements.

Let me point out that there was a rechartering debate in 2013 which
included lots of discussion about requirements, and about 16 drafts in
between then and now. What you want is to go back to the drawing board
because you weren't aware of what the IETF was discussing instead of
describing your requirements and what would meet them. Huge amounts of
protocol analysis will need to be redone as a result: might be good
for some people, but we're already far behind schedule and with lots
of unresolved issues.

> Again, let me restate,  I don't think anyone is saying that we MUST have RSA.    But, we, as the clients of the IETF TLS protocol, would like to work with you to assure we have workable, manageable…

You can use static ephemeral shares on the server side if you want. Is
that good enough? You can do what Brian Sniffen described above, and
you have 1.5 decades to shift or so.

---

From: Hovav Shacham <[email-masked]>
Date: Sun, 25 Sep 2016 18:19:31 -0700

On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael <[email-masked]>
wrote:

>
> Again, let me restate,  I don't think anyone is saying that we MUST have
> RSA.    But, we, as the clients of the IETF TLS protocol, would like to
> work with you to assure we have workable, manageable  and affordable
> solutions,  that meets our needs as well as the needs of others.
>

I think TLS 1.3 as it is might actually be compatible with your
requirements.  The technology you need, Dual EC, was developed by the US
Government and has already been standardized by ANSI X9.  Here's a
whitepaper on how it would work:

    http://dualec.org/DualECTLS.pdf

There are some organizations that would no doubt be happy to lend their
expertise, including RSA-the-company.

-hs.

---

From: [email-masked] (Martin Rex)
Date: Mon, 26 Sep 2016 09:57:31 +0200 (CEST)

> Qualys), or browser extensions for the security conscious (e.g. CertPatrol).

With FREAK and LOGJAM attacks, there is a significant difference in
effort between servers using a static private (DH or temporary RSA) key
vs. truely ephemeral key.  But security checks of "vulnerability scanners"
do not seem to do any checks on whether the server is presenting the
same public key on multiple handshakes.

Generation of truely ephemeral DH keys for every full handshake is IMO
quite expensive for 2048+ bits DH.  The reason why I like Curve25519
is that generation of ephemeral keys is cheap.

-Martin

---

From: Pascal Urien <[email-masked]>
Date: Mon, 26 Sep 2016 10:28:29 +0200

Hi All

There is a smart way to recover DH secret by a third party

It is DH tripartite base on EC paring

https://tools.ietf.org/html/draft-urien-tls-dh-tripartite-00

Rgs

Pascal

2016-09-25 23:20 GMT+02:00 Ackermann, Michael <[email-masked]>:

> I understand your concern over what the nation-state actors are doing but
> it is not the same as what Enterprises do to manage their private servers,
> networks and clients.
>
> Your final paragraph is quite a constructive question.   "What
> specifically would you have us do? What do you want in the protocol that
> enables your needs, but doesn't make it possible for everyone in the world
> to be surveilled?  Please, make some specific suggestions."
>
> My personal perspective would be, that the approach to achieving an answer
> to that important question, would start with:
>
> 1.  Gathering  protocol neutral requirements from all involved factions,
> (with help and suggestions from people on the TLS list)
>
> 2.   Brainstorming session(s) with people on the TLS list as well
> potential users/operators, with objectives that include the design of a
> solution that meets (hopefully) all known requirements.
>
> What I would like to see come out of the debate we seem to be currently
> involved in,  is the realization that significant operational/management
> issues exist with TLS 1.3 and that the IETF is taking them seriously enough
> to at least begin dialogue intended to address these issues, and
> potentially work together to craft related solution(s).   In my view this
> issue is far too complex &  pervasive to believe that any one person or
> group's perspective would produce a viable overall solution.
>
> To: Ackermann, Michael <[email-masked]>; Pawel Jakub Dawidek <
> [email-masked]>; [email-masked]
> At the risk of repeating myself and flogging this dead horse...  What you
> are doing is exactly what the nation-state actors are doing.  I bet that
> some even use that exact phrase of "packet collection infrastructure."
>
> I understand that if you want to use TLS 1.3, it is going to be expensive
> and/or inconvenient; you're going to have to educate regulators and get
> bespoke TLS endpoint solutions from vendors. Perhaps you can get the NSA's
> to stop collecting everyone's Internet traffic for future decoding?
>
> Less flippantly, what specifically would you have us do? What do you want
> in the protocol that enables your needs, but doesn't make it possible for
> everyone in the world to be surveilled?  Please, make some specific
> suggestions.
>
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Sep 2016 12:33:02 +0000

> I understand your concern over what the nation-state actors are doing but it
> is not the same as what Enterprises do to manage their private servers,
> networks and clients.

Okay, in technical terms only, what is the difference?
 
> to that important question, would start with:

It's too late for that.  We're at the end-game, not the start.  I'm only a WG member, not editor, chair, or Area Director, but I would be extremely surprised if there was any consensus to delay things.  

> involved in,  is the realization that significant operational/management

I hope you don't take this the wrong way, but I don't see that we're having a debate. I see a couple of new WG members re-raising an issue that the WG decided years ago.  And that the rest of the WG is pretty consistently expressing their, shall we call it, lack of interest?  And some people have offered TLS 1.2, end-point-based interception, and static key shares as ways to address it.  And I haven’t seen a response to those suggestions.

Your most effective course of action is to come up with a specific proposal, and probably within a week or two.

---

From: [email-masked] (Martin Rex)
Date: Mon, 26 Sep 2016 16:55:34 +0200 (CEST)

> debug, but also look for data leaks, malware, etc.

There may be a some countries with poor civil liberty protections
where such activies (employee communication surveillance) has
not been criminalized yet, but at least in the European Union,
there is EU Directive 2002/58/EC which requires member states to
criminalize such surveillance.  In Germany, this was criminalized
with the 2004 update of the TKG (Telekommunikationsgesetz) and
will get every employer up to 5 years prison term for doing this.

And no, there can not be any valid regulations to require such
monitoring, because _every_ to the secrecy provisions and criminalization
requires an explicit law from the parlamentarian legislator.

"regulations" are issued by parts of the government (executive power),
and the German national law (TKG) and the German constitution (GG)
formally excludes the executive power from defining/creating exceptions
to telecommunication secrecy.

-Martin

---

From: BITS Security <[email-masked]>
Date: Mon, 26 Sep 2016 19:01:11 +0000

Peter- 

Outbound TLS connections require MITM for decryption.  Inbound or internal TLS connections can be decrypted with an RSA private key under TLS 1.2. 

The PCI DSS is already requiring TLS 1.2 for financial institutions that participate in the Payment Card Industry.  .BANK (exclusive top level banking domain) is also planning to require TLS 1.2.   We're anticipating that a regulatory body like these will require TLS 1.3 at some point in the future.  Financial institutions then have to comply if they want to continue to do business with the companies represented by the regulatory body (like large credit card companies in the case of PCI).

-Andrew

-----Original Message-----
From: Peter Bowen [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

>  we need a better option than TLS 1.2 that will, perhaps sooner than we might expect, be deprecated.

I'm somewhat confused here.  The concern over RSA for key exchange versus DH for key exchange would only seem to apply when the network tapping system has access to the RSA key, right?  So the part of this about monitoring the network for external chat and such doesn't really change if the client is using TLS 1.1 or 1.3, as you still can't decrypt the connection just from monitoring, right?

If that is true, then it implies that the server is at least somewhat under control of the monitor, so it can support TLS 1.2 as long as needed.  TLS 1.0 came out in 1999 and is still now (in 2016) widely deployed.  While I hope TLS 1.3 deployment is speedy, I don't forsee browsers dropping TLS 1.2 and earlier support any time soon.

Thanks,
Peter

---

From: BITS Security <[email-masked]>
Date: Mon, 26 Sep 2016 19:23:28 +0000

Bill--We believe it isn't a binary choice between maximizing public Internet security and minimizing enterprise risk.  I am not advocating for a particular solution but if social media chooses to use PFS only that is fine with us and likely we would use PFS is many public Internet situations as well.  

That said, at least one of the sites you mentioned was known to have an APT inside their perimeter (Operation Aurora) for about a month and part of the tactics within that attack which was publicly reported was the use of "SSL" to mask C&C communications.  That's the type of threat we are concerned about inside of the enterprise network and we need visibility (and flexibility appropriate to our network design and risk tolerance) to solve for these issues in way that protects people like the ones you mentioned.  

End-point monitoring while useful has a lot of limitations:  logging issues, often can't meet packet capture requirements, etc.  We are not against end-point monitoring and do consider it a tool in the toolkit but it simply can't adequately replace robust network security monitoring tools.  

- Andrew 

-----Original Message-----
From: Bill Frantz [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 9:31 PM
To: BITS Security <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Security) wrote:

>services) which don’t have an explicit man-in-the-middle (and don’t 
>permit server-side access to user plaintext and can’t be observed by 
>other means) can’t be used in supervised environments. This rules out 
>many cloud-hosted services today.

The public internet, Google, Cloud services, Facebook, Twitter, etc. etc. move in the direction of improving security using things like PFS, because the idea of protecting human rights advocates in the parts of the world where people are routinely tortured sells well to the general public, people like me, and others on this list.

On the other hand, some major enterprises continue to depend on being able to break the security of their employees to monitor their networks in ways that the bad guys can easily use, as opposed to installing endpoint or gateway monitoring.

This train wreck results in fewer and fewer public internet services being available to users within these enterprises. 
Eventually, employees give up on the corporate network and start using their cell phones to communicate with customers, research investments etc., completely bypassing the regulatory required monitoring.

This scenario says it doesn't matter whether TLS 1.3 and successors allows RSA. If they have any PFS modes, these will be the only ones public internet servers will accept. If they are turned off in enterprise clients, they will not be able to connect without going through a gateway which turns them on.

My conclusion is that enterprises that depend on being able to decrypt traffic without involving the endpoints should start moving to systems that do involve the endpoints.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Ham radio contesting is a    | Periwinkle
(408)356-8506      | contact sport.               | 16345 
Englewood Ave
www.pwpconsult.com |  - Ken Widelitz K6LA / VY2TT | Los Gatos, CA 95032

---

From: BITS Security <[email-masked]>
Date: Mon, 26 Sep 2016 19:43:02 +0000

Hi Brian--Thanks for the practitioner comment.  

Something perhaps worth mentioning here is that there often isn't just one support team inside an enterprise.  There are application support teams for each application, network support people, security engineering support people, server support people, desktop support people, mainframe support people, packet analysis teams.  All of them use different methods, and often each doesn't know details about how the other teams work.  Some of these teams do work at the endpoints but many gain visibility through other means (at least in the FS industry).  

-Andrew 

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Brian Sniffen
Sent: Saturday, September 24, 2016 11:31 PM
To: [email-masked]; Watson Ladd <[email-masked]>; Ackermann, Michael <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

> involved in this conversation.

Hi, technical person most directly responsible for incident response and urgent debugging here.  We modify endpoints to get what we need.  We did have taps that relied on knowing the RSA Kx secret... but haven't used them in about a decade.

I think the banks have an answer not available to the global passive
adversaries: modify the server or client to use a fixed ECDH share, then use tech much like their current choices.  It'll take a while to develop, but nobody in that environment plans to move to TLS 1.3 for operational systems any time soon anyway.

-Brian

> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so. Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).
> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we might do them the courtesy of not thinking that they are foolish to do so. Why don't we listen to each other?   I know at IETF, I often hear that we don't get enough operators to comment and give feedback.  Well, here you have some.  It may be that these companies have problems that are different from Google's (just as an example).

--
Brian Sniffen
Akamai Technologies

---

From: Xiaoyin Liu <[email-masked]>
Date: Mon, 26 Sep 2016 20:12:03 +0000

Andrew,

Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks. Also, unlike SSL 3.0 – TLS 1.1, TLS 1.2 is not currently known to be weak or insecure, if properly implemented and not using insecure cipher suites. So in my opinion, it makes sense to keep using TLS 1.2 internally.

Best,

Xiaoyin

From: BITS Security<mailto:[email-masked]>
Sent: Monday, September 26, 2016 3:02 PM
To: Peter Bowen<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Peter-

-Andrew

-----Original Message-----
From: Peter Bowen [mailto:[email-masked]]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Thanks,
Peter

---

From: Andrei Popov <[email-masked]>
Date: Mon, 26 Sep 2016 20:51:53 +0000

?  Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks.

?  So in my opinion, it makes sense to keep using TLS 1.2 internally.
Won't the TLS WG stop addressing newly found protocol-level security issues in TLS 1.2 at some point in the future? I don't think financial institutions' internal networks can stay on TLS 1.2 indefinitely.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Xiaoyin Liu
Sent: Monday, September 26, 2016 1:12 PM
To: BITS Security <[email-masked]>; Peter Bowen <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Andrew,

Then I think your option is to persuade the regulators not to require TLS 1.3 for internal networks. Also, unlike SSL 3.0 - TLS 1.1, TLS 1.2 is not currently known to be weak or insecure, if properly implemented and not using insecure cipher suites. So in my opinion, it makes sense to keep using TLS 1.2 internally.

Best,

Xiaoyin

Peter-

-Andrew

-----Original Message-----
From: Peter Bowen [mailto:[email-masked]]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Thanks,
Peter

---

From: Geoffrey Keating <[email-masked]>
Date: 26 Sep 2016 14:45:18 -0700

BITS Security <[email-masked]> writes:

> Outbound TLS connections require MITM for decryption.  Inbound or
> internal TLS connections can be decrypted with an RSA private key
> under TLS 1.2.

It would be unwise to build a security or regulatory structure on the
principle that MITM will always be possible.  This is especially true
for the kinds of popular and frequently attacked services for which
DLP might be important, like Facebook, Twitter, Google, Apple,
Dropbox, Github.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 26 Sep 2016 19:09:48 -0400

> On Sep 26, 2016, at 3:23 PM, BITS Security <[email-masked]> wrote:
> 

I very much doubt that the APT C&C traffic went out of its way to use
RSA key exchange to make the traffic enterprise-friendly, or even if
it happened to use RSA key exchange that the private keys were available
to the victim site...

All that RSA key exchange gives you is the ability to use long-term
keys of servers you control to decrypt past traffic through that server
if the private keys are still (or for better or worse become) available.

There are other ways to accomplish this.  For example, the server might
use session ticket keys that are stored centrally encrypted under a
suitable escrow key.  If clients always enable session tickets, then
every handshake will result in the server returning a session ticket,
in which case the session can be later decrypted if the session ticket
keys are available.

There's no need to change to the TLS protocol to make such things
possible, it is sufficient to purchase server devices that in one
way or another record session master secrets for later recovery.

There will surely be vendors who'll be more than happy to be paid
to fulfill any business needs in this space.

Having worked in IT security in the financial services industry for
more than a couple of decades now, I am rather surprised and somewhat
appalled by this thread.  I don't believe that the concerns raised
should in any way influence protocol design.  Products that offer less
forward-secrecy than the protocol would otherwise deliver will be
available to those who control either or both end-points and need
to be able to be able to produce after-the-fact plaintext.

The good news about doing key escrow deliberately, rather than
as an unintended side-effect of RSA key exchange, is that it
can be both more reliable and more secure, since the escrow
private keys need not be the same as the server long-term
authentication keys, and are therefor less vulnerable.

RSA key exchange has a long history of problems, and it is time to
move on.  We should not be overly attached to one particular way of
doing key escrow.

-- 
-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Sep 2016 16:21:53 -0700

> in which case the session can be later decrypted if the session ticket

This actually doesn't work in TLS 1.3 because the resumption master secret
is not sufficient to decrypt the connection in which it was established.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 26 Sep 2016 20:20:33 -0400

> On Sep 26, 2016, at 7:21 PM, Eric Rescorla <[email-masked]> wrote:
> 

Yes, I know that changed.  It was an example of something that works with
TLS 1.2 even when PFS is used.  With TLS 1.3 server or client implementations
can find other ways to retain long-term records of session keys.  The capability
to do that is not a requisite or desirable protocol feature.  Different user
communities will have different needs, and the best solution is to provide
security by default, and cede control of the result to the endpoints.

-- 
	Viktor.

---

From: Judson Wilson <[email-masked]>
Date: Tue, 27 Sep 2016 01:33:05 -0700

> security by default, and cede control of the result to the endpoints.

I don't believe that storing this information on the endpoints is a great
idea, simply because the monitoring equipment will have a difficult time
ensuring that the information exists when it is needed. It also increases
the number of sites that are risks to compromising past data.

I think this challenge is best solved by putting the information on the
wire in some way, possibly as a special industry-specific extension (used
only by those who are bent on shooting themselves in the foot). The benefit
being that if the TLS channel is alive, the session information is
available to the monitor.  Just as a strawman, the client could transmit
session info in special records, encrypted by a public key, and the
monitoring equipment could scoop these up. For compatibility with servers
outside the network, a middlebox could somehow filter out these records.

It sounds like the need is large enough that such an effort is feasible,
and it would be good to keep normal TLS 1.3 unambiguously forward secure.
(There IS still the question of how to make sure that the extension is not
enabled in endpoints it shouldn't be.)

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 27 Sep 2016 11:52:49 +0000

Andrei Popov <[email-masked]> writes:

>Won’t the TLS WG stop addressing newly found protocol-level security issues
>in TLS 1.2 at some point in the future?

They already have, which is the point of TLS-LTS.  Since that fixes all known
issues (and that also includes long-standing generic problems like use of MtE
that's led to a string of vulns stretching over years), it could well be the
last updated needed for 1.2.

Peter.

---

From: BITS Security <[email-masked]>
Date: Tue, 27 Sep 2016 18:07:28 +0000

Hi Eric--Thank you for the prompt.  

Our requirements are for the same capabilities we have today with TLS 1.2, namely to be able to take a trace anywhere in our enterprise and decrypt it out of band (assuming that we own the TLS server).  This includes traces taken from physical taps, traces from span or mirror ports, traces from the virtual environment, and/or traces from agents on workstations.  We need to be able to apply a key to sniffer devices, security and fraud monitoring tools, APM devices, and/or TLS decryption appliances.  

Outbound TLS today requires an MITM/proxy solution in order to decrypt TLS.  One visibility point only in this environment is not adequate to cover every situation especially in a crisis (whether a broken app or a more nefarious concern like APT).  

- Andrew

From: Eric Rescorla [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 4:43 PM
To: BITS Security <[email-masked]>
Cc: Salz, Rich <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Andrew,

What would probably be most helpful here would be if you tried to describe what you think your requirements are in some sort of protocol-neutral fashion.

-Ekr

On Fri, Sep 23, 2016 at 1:31 PM, BITS Security <[email-masked]> wrote:
Rich (et al.) -- I understand where you are coming from but I will poke a little bit at this portrayal.

-Andrew

---

From: BITS Security <[email-masked]>
Date: Tue, 27 Sep 2016 18:20:54 +0000

The various suggestions for creating fixed/static Diffie Hellman keys raise interesting possibilities.  We would like to understand these ideas better at a technical level and are initiating research into this potential solution.  We need to understand the potential ramifications and other implementation details.  This solution would have to be implemented in servers, firewalls, load balancers, Internet proxies, and mainframes.  If vendors broadly refuse to support then it is not much a solution but at this point looks like it is worth exploring.  

Really appreciate those who brought this to our attention.  

- Andrew

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

If the problem is the use of forward secrecy then there is a simple solution, don't use it.
That is, you can, as a server, have a fixed key_share for which the secret exponent becomes the private key exactly as in the RSA case. It does require some careful analysis, though.

But maybe I misunderstood the problem and maybe I should not be putting these surveillance-friendly ideas in people's minds...

Hugo

On Thu, Sep 22, 2016 at 1:19 PM, BITS Security <[email-masked]> wrote:
To:  IETF TLS 1.3 Working Group Members

Sincerely,

Andrew Kennedy

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 27 Sep 2016 21:24:09 +0300

On Tue, Sep 27, 2016 at 06:07:28PM +0000, BITS Security wrote:
> Our requirements are for the same capabilities we have today with TLS
> 1.2, namely to be able to take a trace anywhere in our enterprise and
> decrypt it out of band (assuming that we own the TLS server).  This
> includes traces taken from physical taps, traces from span or mirror
> ports, traces from the virtual environment, and/or traces from agents
> on workstations.  We need to be able to apply a key to sniffer 
> devices, security and fraud monitoring tools, APM devices, and/or TLS
> decryption appliances.  

No changes to standards are going to happen to make that any easier.
Don't waste your time.

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Sep 2016 21:20:27 +0300

> On 27 Sep 2016, at 11:33 AM, Judson Wilson <[email-masked]> wrote:
> 
> 
> 
> I don't believe that storing this information on the endpoints is a great idea, simply because the monitoring equipment will have a difficult time ensuring that the information exists when it is needed. It also increases the number of sites that are risks to compromising past data. 

Assuming clients are browsers for the most part, storing information there is not robust. The servers or load balancers OTOH are small in number and controllable. If they store a static or time-limited server keyshare or even actual session keys it can be made to work. As for ensuring that the information is stored, that is true regardless of what regulations require to be stored.

> I think this challenge is best solved by putting the information on the wire in some way, possibly as a special industry-specific extension (used only by those who are bent on shooting themselves in the foot).

Like this?
https://tools.ietf.org/html/draft-nir-tls-keyshare-02

But this doesn’t work if you’re using a standard browser. This draft was a strawman proposal for some argument. Even if we liked this and wanted to make this an RFC, I can’t see the likes of Google or Mozilla implementing this in their browsers. Or you’d need a fork of some server-side library. OpenSSL-with-keyshare?  Because I don’t see it popping up in the regular OpenSSL.  That’s a good thing.

> The benefit being that if the TLS channel is alive, the session information is available to the monitor.  Just as a strawman, the client could transmit session info in special records, encrypted by a public key, and the monitoring equipment could scoop these up. For compatibility with servers outside the network, a middlebox could somehow filter out these records.
> 
> It sounds like the need is large enough that such an effort is feasible, and it would be good to keep normal TLS 1.3 unambiguously forward secure. (There IS still the question of how to make sure that the extension is not enabled in endpoints it shouldn't be.)
> 
> On Mon, Sep 26, 2016 at 5:20 PM, Viktor Dukhovni <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> >
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: BITS Security <[email-masked]>
Date: Tue, 27 Sep 2016 18:34:30 +0000

Ilari - I understand yours (and others) view on this but there is no technical reason why this couldn't be part of the standard.  A potential solution, like many cipher suite *choices* in past versions of TLS, would be optional and up to both clients and servers to configure what they are willing to support (or not support).  You appear to be assuming everyone is running off the same set of requirements (one-size-fits-all) and we are here to tell you that isn't necessarily true.  

- Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 27, 2016 2:24 PM
To: BITS Security <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

-Ilari

---

From: Seth David Schoen <[email-masked]>
Date: Tue, 27 Sep 2016 11:30:22 -0700

> The various suggestions for creating fixed/static Diffie Hellman keys raise interesting possibilities.  We would like to understand these ideas better at a technical level and are initiating resear…

Bear in mind that, if you do that, anyone who gets a copy of that secret
will be able to retrospectively decrypt all of your organization's
TLS traffic.  However, that's presumably true of any solution that
satisfies the requirement that you describe: there will always be _some_
secret that the organization possesses that, if obtained by an adversary,
would let the adversary retrospectively decrypt traffic.

This configuration might be a bit dangerous because it means that
"servers, firewalls, load balancers, Internet proxies, and mainframes"
would all possess the information needed to decrypt _each other's_
traffic, so someone inside or outside the organization who can steal
that information can then read all of the traffic, even traffic that was
originated by devices they don't know about or have a relationship to.
So organizational unit X can read the traffic of organizational unit Y,
even if X wasn't meant to be in a supervisory or audit relationship
over Y, because the ability to emit decryptable traffic of this kind
also implies the ability to decrypt others' sessions.

It also provides a way that other parties outside of the organization can,
even through passive eavesdropping, recognize the organization's traffic
as associated with that organization -- kind of like a global cookie
inside the TLS handshake.  People could use that to target surveillance
or advertising even if they didn't know or recognize the organization's
IP address ranges.

-- 
Seth Schoen  <[email-masked]>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

---

From: Michał Staruch <[email-masked]>
Date: Tue, 27 Sep 2016 10:36:27 +0200

> requires an explicit law from the parlamentarian legislator.

GDPR Article 88 leaves rules of processing employees' personal data
in the employment context up to the Member States - so regulations
in Germany may be different than ones in let's say Poland.

About the main topic: TLS main task is to protect privacy and data
integrity - essentially to prevent the MitM. Requests that are in
direct conflict with that can't be treated seriously.

TLS needs to provide secure connections, and PFS cipher suites are
better choice than non-PFS ones. If anyone wants (or needs) to monitor
the data, he should set proper trust boundaries, and do the monitoring
between TLS terminators.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 27 Sep 2016 12:49:59 -0700

On Tue, Sep 27, 2016 at 11:34 AM, BITS Security <
[email-masked]> wrote:
> Ilari - I understand yours (and others) view on this but there is no
technical reason why this couldn't be part of the standard. A potential
solution, like many cipher suite *choices* in past versions of TLS, would
be optional and up to both clients and servers to configure what they are
willing to support (or not support). You appear to be assuming everyone is
running off the same set of requirements (one-size-fits-all) and we are
here to tell you that isn't necessarily true.

Why does the TLS 1.3 document need to include this, as opposed to a
separate extension? I do think you are ignoring the very real weaknesses
your network architecture has: any user account with the ability to decrypt
TLS sessions networkwide can easily be a jumping off point for total
ownage. Many authentication solutions depend on TLS traffic being secure.

Sincerely,
Watson Ladd

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 27 Sep 2016 13:17:15 -0700

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <
[email-masked]> wrote:

> The PCI DSS is already requiring TLS 1.2 for financial institutions that
> participate in the Payment Card Industry.  .BANK (exclusive top level
> banking domain) is also planning to require TLS 1.2.   We're anticipating
> that a regulatory body like these will require TLS 1.3 at some point in the
> future.  Financial institutions then have to comply if they want to
> continue to do business with the companies represented by the regulatory
> body (like large credit card companies in the case of PCI).

Hello again,

I work firsthand enforcing these requirements at a payments company. Again,
I do not speak on behalf of my employer.

It wasn't until last year that PCI decided to deprecate TLS 1.0, at the
time a 16 year old standard. I think your sense of emergency is highly
over-exaggerated.

I find it highly unlikely that any group such as the PCI Council will begin
mandating TLS 1.3 any time soon. I would go as far as to call your concerns
"imaginary".

If you are worried about such an eventuality, the IETF is the wrong place
to complain. It is far, far too late in the TLS 1.3 process to be voicing
these concerns. Where were you 2+ years ago when it was the appropriate
time in the TLS development cycle to voice such concerns? I think the view
of more "forward thinking" payments companies is TLS 1.3 has taken too long
already, and they would like to start deploying it in its current form and
would prefer unnecessary holdups/distractions which have already occurred
throughout the process.

That said, there is still plenty of time to ensure that groups like the PCI
Council do not put in place requirements which would affect the centralized
traffic-decrypting MitM-capability on your payments stack. Perhaps you
should be voicing your concerns there? If you are worried about a TLS 1.3
mandate preventing your MitM capability, the onus is on you to convince the
relevant payments standards bodies that mandating TLS 1.3 is a bad idea for
the payments industry. I think those organizations are better poised to
judge whether such an approach reflects on necessary requirements versus
pervasive antipatterns among complacent companies unprepared for the future
and ripe for a data breach.

In the meantime, you have disclosed a veritable treasure map to a
traffic-decrypting single point of failure which ostensibly exists at all
of the companies you represent which attackers could leverage to recover
all payment credentials. That sounds like a huge security threat.

Would you mind disclosing which companies you represent, so I can ensure
for the safety of my own money that I do not use them?

-- 
Tony Arcieri

---

From: Ronald del Rosario <[email-masked]>
Date: Tue, 27 Sep 2016 21:03:10 +0000

+1 to Tony

I am also in charge of enforcing TLS Standards in our CDE.  I also do not speak on behalf of my employer, but:

PCI extended the migration from SSLv3 and TLS 1.0 to a secure version (TLS 1.1 or higher) until June 2018.<https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls>

Thanks,
Ron

From: TLS <[email-masked]> on behalf of Tony Arcieri <[email-masked]>
Date: Tuesday, September 27, 2016 at 1:17 PM
To: BITS Security <[email-masked]>
Cc: Jeffrey Walton <[email-masked]>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <[email-masked]<mailto:[email-masked]>> wrote:
The PCI DSS is already requiring TLS 1.2 for financial institutions that participate in the Payment Card Industry.  .BANK (exclusive top level banking domain) is also planning to require TLS 1.2.   We're anticipating that a regulatory body like these will require TLS 1.3 at some point in the future.  Financial institutions then have to comply if they want to continue to do business with the companies represented by the regulatory body (like large credit card companies in the case of PCI).

Hello again,

I work firsthand enforcing these requirements at a payments company. Again, I do not speak on behalf of my employer.

It wasn't until last year that PCI decided to deprecate TLS 1.0, at the time a 16 year old standard. I think your sense of emergency is highly over-exaggerated.

I find it highly unlikely that any group such as the PCI Council will begin mandating TLS 1.3 any time soon. I would go as far as to call your concerns "imaginary".

If you are worried about such an eventuality, the IETF is the wrong place to complain. It is far, far too late in the TLS 1.3 process to be voicing these concerns. Where were you 2+ years ago when it was the appropriate time in the TLS development cycle to voice such concerns? I think the view of more "forward thinking" payments companies is TLS 1.3 has taken too long already, and they would like to start deploying it in its current form and would prefer unnecessary holdups/distractions which have already occurred throughout the process.

That said, there is still plenty of time to ensure that groups like the PCI Council do not put in place requirements which would affect the centralized traffic-decrypting MitM-capability on your payments stack. Perhaps you should be voicing your concerns there? If you are worried about a TLS 1.3 mandate preventing your MitM capability, the onus is on you to convince the relevant payments standards bodies that mandating TLS 1.3 is a bad idea for the payments industry. I think those organizations are better poised to judge whether such an approach reflects on necessary requirements versus pervasive antipatterns among complacent companies unprepared for the future and ripe for a data breach.

In the meantime, you have disclosed a veritable treasure map to a traffic-decrypting single point of failure which ostensibly exists at all of the companies you represent which attackers could leverage to recover all payment credentials. That sounds like a huge security threat.

Would you mind disclosing which companies you represent, so I can ensure for the safety of my own money that I do not use them?

--
Tony Arcieri

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.

---

From: Seth David Schoen <[email-masked]>
Date: Tue, 27 Sep 2016 17:17:11 -0700

> originated by devices they don't know about or have a relationship to.

Existing tools may not support this very well out of the box, but a
somewhat safer technique if you want to decrypt sessions of devices that
you administer would be to have the devices produce their DH parameters
using device-specific or at least organizational unit-specific secrets,
ideally ones that change regularly over time.

People with audit authority can then know all of the secrets, but they
don't have to be known to everyone in the entire organization, and a
device doesn't need to have the information necessary to decrypt all
the prior traffic that it generated.

It's still hard for the audit unit to be confident that it's destroyed all
the copies of old secrets, and the audit unit is still a juicy target for
an attacker who wants to compromise a lot of traffic, but at least there
wouldn't be extremely valuable long-term organization-wide cryptographic
secrets on nearly every device in the organization!

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Sep 2016 01:29:19 +0100

On 28/09/16 01:17, Seth David Schoen wrote:
> People with audit authority can then know all of the secrets,

How well does that whole audit thing work in the financial services
industry?  (Sorry, couldn't resist:-)

S.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 28 Sep 2016 09:15:02 +0200

Hi Andrew,

I am coming from a different industry, the embedded industry, and for us
at ARM the development of TLS 1.3 will help us to increase the security
of Internet of Things devices as well as to improve the performance of
the handshake. We are reaching out to developers and our partners to
tell them about the importance of randomness and keys generated on on
low end microcontrollers.

From reading your text it feels that you have been relying on technology
that intercepts security protocols in a way that follows an
architectural model that wasn't necessarily sound to begin with. Maybe
it is time to rethink the architectural choices you have made or at
least challenge your favorite deep packet inspection vendors a bit more.

Ciao
Hannes

On 09/22/2016 07:19 PM, BITS Security wrote:
> 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.
>
> operations; and advocate member, sector, cross-sector, and
> private-public collaboration.
>
> 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.
>
> 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
> 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.
>
> 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.
>
> 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.
>
> management complexity, and production risk at each of the needed
> monitoring layers.
>
> 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
>
>
>
>
> _______________________________________________ TLS mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 Sep 2016 11:01:43 +0200 (CEST)

> enabled in endpoints it shouldn't be.)

Whoa there.  What you're describing is essentially the
Clipper-Chip & Skipjack encryption

https://en.wikipedia.org/wiki/Skipjack_(cipher)

I'm sorry, but the IETF decided back then that it doesn't want
to standardize such technology:

https://tools.ietf.org/html/rfc1984

I'm sorry, but I'm still violently opposed to the IETF endorsing
backdooring of security protocols.

-Martin

---

From: Joachim Strömbergson <[email-masked]>
Date: Wed, 28 Sep 2016 11:34:50 +0200

Aloha!

Salz, Rich wrote:
>> I understand your concern over what the nation-state actors are
>> doing but it is not the same as what Enterprises do to manage their
>> private servers, networks and clients.
> 
>> My personal perspective would be, that the approach to achieving an
>> answer to that important question, would start with:
> 
> It's too late for that.  We're at the end-game, not the start.  I'm
> only a WG member, not editor, chair, or Area Director, but I would be
> extremely surprised if there was any consensus to delay things.

This whole thread looks scarily close to an attempt at throwing a
spanner into the machinery.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          [email-masked]
========================================================================

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 Sep 2016 15:29:35 +0200 (CEST)

> industry?  (Sorry, couldn't resist:-)

I am actually having serious doubts that it works at all.

Consider a scenario that uses TLSv1.2 with static-RSA key exchange,
plain old session caching and Microsoft style renego-client-cert-auth
on a subset of the urlspace.

(1) first TLS session, full handshake, request to public area.

(2) TLS session resume, request to non-public area -> renego

(3) TLS session resume for renego'ed session to non-public area.

To obtain the cleartext of session (3), you'll need the master secret
of the renego'ed session from (2), for which you'll first have to locate
and decrypt (2), for which you need the master secret from (1), so you'll
have to locate (1), and only at (1) you can start opening the encryption
with the longterm private RSA key of the server.

It is impossible to open (3) directly, and the ClientKeyExchange
handshake message (and client&server randoms) that created the master secret
of session (3) is encrypted during renegotiation, so one can not
directly recover that with the longterm private RSA key of the server,
but has to open (2) first.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 28 Sep 2016 15:34:41 +0200 (CEST)

> but has to open (2) first.

And it might even be more difficult than that.

Because the Server Hello (with the server-issued new session_id)
is encrypted during renegotiation, one can not see which renegotiation
created the session that is resumed in (3), and may have to decrypt
several renegotiation handshakes in order to find the correct one
which created the session_id (3).

-Martin

---

From: Dan Brown <[email-masked]>
Date: Wed, 28 Sep 2016 16:16:20 +0000

As I understand the concern, the worry is that Bud is compromising Bob's (TLS) server, to somehow send Bob's plaintext to the wrong place.

The proposed (existing?) strategy has Bob compromising his own forward-secrecy to stop Bud, but only after the cat is out of the bag. This seems a high price (no forward-secrecy) to pay for little gain (cat-out-of-bag).

It seems wiser for Bob to somehow monitor or log what is being done with his own plaintexts at his own server. I know little about existing products to do this, but from my theoretical perspective, it ought to be easier than compromising forward-secrecy (logging ciphertexts).

If proper plaintext monitoring or logging is somehow too costly, then yes, as Hovav Shacham mentions, it seems possible that Bob can try to escrow ephemeral keys instead, by logging them (or their ultimate source, e.g. OS RNG), or by deriving them from say HMAC-DRBG, with prediction-resistance turned off, and just logging the DRBG seed (far out of reach of Bud, etc.).  This is still only a cat-out-of-bag solution, and also jeopardizes forward-secrecy.

Does TLS 1.3 already have a countermeasure to something like that?

If not, then maybe a future TLS 1.4, could go a step further to boost forward-secrecy, in partially thwarting Bob from escrowing himself (as outlined above).  For example:

http://eprint.iacr.org/2014/876

the gist of which, as I recall, is deriving ephemeral keys from both a randomness source and the plaintext to be sent.  If the plaintext has enough entropy (and Bob does not keep a copy), then even escrowed keys are not enough to recover the plaintext.

In my limited understanding, this would be infeasible in the TLS setting, because it seems to require during a TLS handshake, collecting entropy from the message queue to derive keys, which might be violation of network layering, etc.  (there's no way for a TLS implementation, to know what's in the message pipeline).  I also doubt that most TLS server would have plaintexts with enough secret entropy waiting in the pipeline before the handshake.  But, again, I could be wrong: maybe TLS 1.3 is doing this in its 0-RTT mode (I haven't followed the details enough to know).

Finally, a historical note: ANSI X9.63 was developed in the late 90's within X9, a committee ostensibly of the financial services industry. ANSI X9.63 specifies some forward-secure forms key agreement. I don't recall any objections to forward-secrecy being raised (but maybe because these forward-secure key agreement were optional, or not just not being adopted.)

Best regards,

Dan

________________________________
From: TLS [[email-masked]] on behalf of Hovav Shacham [[email-masked]]
Sent: Sunday, September 25, 2016 9:19 PM
To: [email-masked]
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael <[email-masked]<mailto:[email-masked]>> wrote:

I think TLS 1.3 as it is might actually be compatible with your requirements.  The technology you need, Dual EC, was developed by the US Government and has already been standardized by ANSI X9.  Here's a whitepaper on how it would work:

There are some organizations that would no doubt be happy to lend their expertise, including RSA-the-company.

-hs.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 28 Sep 2016 12:29:03 -0400

> It seems wiser for Bob to somehow monitor or log what is being done with his
> own plaintexts at his own server. I know little about existing products to
> do this, but from my theoretical perspective, it ought to be easier than
> compromising forward-secrecy (logging ciphertexts).

+1. I worked on two separate projects where all messages were
effectively duplicated - one was sent as expected and the other was
sent to a logging server. It did not matter what the message was. It
could have been email, chat a pdf or a word doc. Everything was logged
by order of the auditor.

One project was for the state department, and the other was diplomatic
security service. They did not care about efficiency. After the
Manning breach and some other classified leaks, they cared very much
about exactly what was egressed.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Sep 2016 20:51:25 +0300

> On 28 Sep 2016, at 7:16 PM, Dan Brown <[email-masked]> wrote:
> 
> If proper plaintext monitoring or logging is somehow too costly, then yes...

I don’t really understand under what circumstances logging, monitoring or storing the plaintext is not feasible, while storing the ciphertext is. Because if you don’t store the ciphertext, then keeping static or ephemeral keys around doesn’t buy you much.  It’s true that current server products don’t log or store the plaintext, but they could easily be modified to do that. There are extensions to browsers that store the plaintext if you want.

Maybe if the good folks at the Bluffdale facility are willing to let you download their copy of your captured ciphertexts, then it makes sense to store only ephemeral or static keys. Otherwise it seems cheaper to store the plaintext than to store both ciphertext and keys.

Yoav

---

From: Dan Brown <[email-masked]>
Date: Wed, 28 Sep 2016 18:57:30 +0000

Please keep aiming for forward-secrecy. (Just in case my wording has been unclear.)

From: Yoav Nir [mailto:[email-masked]] 
Sent: Wednesday, September 28, 2016 1:51 PM

>On 28 Sep 2016, at 7:16 PM, Dan Brown <mailto:[email-masked]> wrote:
 
>> I know little about existing products to do this, but from my theoretical perspective, it ought to be easier than compromising forward-secrecy (logging ciphertexts).

>I don’t really understand under what circumstances logging, monitoring or storing the plaintext is not feasible, while storing the ciphertext is. 

I don't understand either.  (That's what I meant by "ought to be easier", sorry for my convoluted phrasing if I was unclear).    

I did not fully understand the earlier parts of this thread, but I thought some were arguing that ciphertext logging was more feasible than plaintext logging.  So, I used "somehow" to qualify this as only a remote possibility in the rest of my email (concerning hypotheticals).  

>Because if you don’t store the ciphertext, then keeping static or ephemeral keys around doesn’t buy you much.  It’s true that current server products don’t log or store the plaintext, but they could easily be modified to do that. There are extensions to browsers that store the plaintext if you want.

Good point, and pretty much my reasoning.

A speculation about costs of storing plaintexts versus ciphertexts: Bob may want to configure his server not to store personal information, e.g. unencrypted plaintexts about his honest customers (Alice).  Of course, it should be sort-of-okay if Bob encrypts and store them at this server (or some other safer location).  But then, Bob might notice the TLS is already encrypting the plaintexts, so he may reason that it is okay to leverage that cost by just capturing those ciphertexts and store them, rather than encrypting them again (now with two different keys).  It's slightly safer, but slightly more costly, for Bob to re-encrypt the plaintexts, because TLS ciphertexts might leave Bob's control (so forward secrecy is very important), whereas the re-encrypted ones can be kept in Bob's control (making them slightly less available to a forward-secrecy-type adversary).  

Finally, Bob monitoring his plaintexts, to stop Bud before he does the bad stuff, might be more costly than storing or logging data, because it involves intelligent processing of sensitive information.  An ounce of prevention is worth a pound of cure; the extra cost of monitoring may be worth it.  Furthermore, if good plaintext monitoring is possible, then Bob need not store ciphertexts or escrowed keys at all, which is worthwhile too, as Alice and Bob then can have better forward secrecy.

---

From: Bill Frantz <[email-masked]>
Date: Wed, 28 Sep 2016 16:08:37 -0700

>backdooring of security protocols.

I find myself in violent agreement with Martin, and many others 
in the IETF.

The last major backdoored encryption protocol I can remember 
came from the National Security Agency. After a few years of 
examination, serious flaws were found in the backdoor mechanism 
which would allow attackers to open the backdoors and read the 
plaintext. When the best in the business can't get these 
protocols right, I don't think we can either.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Since the IBM Selectric, keyboards have gotten
408-356-8506       | steadily worse. Now we have touchscreen keyboards.
www.pwpconsult.com | Can we make something even worse?

---

From: Melinda Shore <[email-masked]>
Date: Wed, 28 Sep 2016 15:27:09 -0800

On 9/28/16 3:08 PM, Bill Frantz wrote:
> I find myself in violent agreement with Martin, and many others in the
> IETF.

This seems uncontroversial and frankly somewhat low-information.
Yay, crypto backdoors are bad.

That said, IETF participation is dominated by large equipment and
software vendors and the problem space, at least until recently
(there's been a crop of data center-related problems coming up in
OPS and routing), has tended to cover service provider-related
questions.  We have poor participation and representation from
enterprise networks.  So now we've got someone showing up from
the enterprise space and saying "I have this problem related to
protocol changes."  And yeah, he's very, very late in this
process, although it's worth pointing out that it's in the best
tradition of the IETF to deal with technical problems that crop
up with documents at any point in their development.

It seems to me that the discussions of alternatives to modifying
the protocol to meet his needs has been extremely helpful, and it
also seems to me that in some sense this ought to be an object
lesson to large enterprises dealing with fairly sophisticated
protocol problems that they really need to get involved and make
their requirements known.  If there's a need here for a new
monitoring framework that doesn't involve compromising the
security of IETF protocols, that strikes me as an interesting
question.  In the meantime I'd hate to see this level of hectoring
continue - we need more participation from other kinds of network
operators, not less.

Melinda

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 28 Sep 2016 17:36:44 -0700

On Wed, Sep 28, 2016 at 4:27 PM, Melinda Shore <[email-masked]

> We have poor participation and representation from

"BITS Security" is representing *some* companies in the payments space,
namely these ones: http://fsroundtable.org/members/

Their concerns are not representative of "the enterprise", "the industry",
"the payments space", etc. In fact some of the companies in the
aforementioned link have personally contacted me to note they disagree with
"BITS Security". Even among their cabal, their opinion is contentious.

My personal opinion, as a security professional directly working on
implementing TLS for a payments company, is their last-minute proposed
changes would harm the security of our payments platform. I want to deploy
TLS 1.3 in its current form. I also think the reasoning for their proposed
changes is based on flawed premises.

There are relevant industry groups BITS Security seems actually concerned
with, such as the PCI Council. BITS Security should be voicing their
concerns there, and the PCI Council should be working with the IETF to
implement such changes if they're actually deemed necessary.

I do not think this is a case of the IETF failing to understand "industry
requirements". I strongly disagree the proposal represents "industry
requirements" at all. I think they are trying to subvert the IETF process
because they have inadequate security processes and they do not want to see
their inadequate processes disturbed by security improvements to TLS.

As a payments professional, my personal opinion is improving the security
of TLS is *paramount*. The voiced concerns are not representative of
"enterprise", "industry", or "payments" as a whole, but an last-minute
opinion of companies who haven't been paying attention to the process who
do not want to invest in upgrading their security practices.

The IETF is doing great work. This entire thread is a distraction, and I
hope it does not result in changes which weaken TLS 1.3's security.

-- 
Tony Arcieri

---

From: Melinda Shore <[email-masked]>
Date: Wed, 28 Sep 2016 16:49:55 -0800

> hope it does not result in changes which weaken TLS 1.3's security.

I think it's quite clearly the case that that is not going to happen.
But, that doesn't mean that these guys don't have a problem worth
addressing, even if they're asking for a crap solution to it.  The
IETF is an insular organization and I tend to think that leads to
poorer outcomes in some cases than we might otherwise have produced.

I am not suggesting that his request for a protocol that he
can break needs serious consideration, but that the fact that he's
come up with an unacceptable solution to a problem that he's
identified doesn't mean that the problem either doesn't exist or
is completely outside the IETF's scope.

All that's going to come out of discussion here is unhelpful
and largely redundant finger-wagging.  I think these guys ought
to write up the problem they've got and post a draft.

Melinda

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 28 Sep 2016 18:03:41 -0700

On Wed, Sep 28, 2016 at 5:49 PM, Melinda Shore <[email-masked]

> poorer outcomes in some cases than we might otherwise have produced.

Their argument is the PCI council will mandate TLS 1.3 soon. This is not
the case. A TLS *1.1* mandate by the PCI council has been delayed until
2018.

I work for a company that directly participates in the PCI council, and
have been participating in the TLS and CFRG process for several years
(again, I do not directly represent either in this discussion).

I do not think that TLS 1.3 in its current form will cause them any
practical real-world problems for these companies, rather they seem to be
attempting to futureproof their current bad practices.

-- 
Tony Arcieri

---

From: Bill Frantz <[email-masked]>
Date: Wed, 28 Sep 2016 22:27:54 -0700

On 9/28/16 at 4:27 PM, [email-masked] (Melinda 

>up with documents at any point in their development.

While I fully support trying to design protocols so applications 
and networks can be managed by enterprises (and indeed home 
users), I do not want to see IETF security protocols become more 
complex as a result. That will only make them easy targets for 
attackers. The Clipper chip shows what happens when even experts 
design key recovery systems.

I hope one outcome of this thread is that industry groups which 
use IETF protocols will realize that the best way to have their 
needs recognized is to be active in the relevant groups from the 
beginning and for the long term. I know of no other way to make 
the proper tradeoffs except to have all the issues in front of 
the working group from the beginning of their process. That 
involvement will strengthen the IETF while making sure 
enterprise issues are addressed.

Even as late comers to the process, BITS Security has gotten a 
number of suggestions for ways forward which do not change the 
emerging TLS 1.3 standard. Given that it will be several years 
before regulators require TLS 1.3, vendors will be able step 
forward to fill this need with endpoint logging as well as other 
techniques embedded in "install and run" products. Given the 
list of companies that Tony linked, these products should enjoy 
a profitable market.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 
Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, 
CA 95032

---

From: Hubert Kario <[email-masked]>
Date: Thu, 29 Sep 2016 13:38:16 +0200

> here to tell you that isn't necessarily true.

if you're willing to forge One Ring to rule them all, using static server key 
shares in TLSv1.3 doesn't change anything in your ability to compromise 
security of all the connections in your network. It also doesn't require any 
changes to TLSv1.3 to work. Yes, it will require changes to MitM boxes and 
decryption software, but that's the case for any new protocol version, isn't 
it?