Re: [TLS] Industry Concerns about TLS 1.3

[Stephen Farrell]

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.



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Seth David Schoen]

Seth David Schoen writes:

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

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!

-- 
Seth Schoen  
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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Ronald del Rosario]

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

Thanks,
Ron

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

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security 
> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Tony Arcieri]

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <
bitssecur...@fsroundtable.org> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Watson Ladd]

On Tue, Sep 27, 2016 at 11:34 AM, BITS Security <
bitssecur...@fsroundtable.org> 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
>
> - Andrew
>
>
>
>
> -Original Message-
> From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com]
> Sent: Tuesday, September 27, 2016 2:24 PM
> To: BITS Security 
> Cc: Eric Rescorla ; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote:
>> 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.
>
> No changes to standards are going to happen to make that any easier.
> Don't waste your time.
>
>
> -Ilari
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Michał Staruch]

On Mon, Sep 26, 2016 at 4:55 PM, Martin Rex  wrote:
> 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.

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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Seth David Schoen]

BITS Security writes:

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

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

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: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] 
Sent: Tuesday, September 27, 2016 2:24 PM
To: BITS Security 
Cc: Eric Rescorla ; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote:
> 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.

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


-Ilari
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Yoav Nir]

> On 27 Sep 2016, at 11:33 AM, Judson Wilson  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.
> 
> 
> 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  > wrote:
> 
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla  > > wrote:
> >
> > 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.
> >
> > 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.
> 
> 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.
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Ilari Liusvaara]

On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote:
> 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.  

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


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

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: hugok...@gmail.com [mailto:hugok...@gmail.com] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security 
Cc: tls@ietf.org
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  
wrote:
To:  IETF TLS 1.3 Working Group Members

My name is Andrew Kennedy and I work at BITS, the technology policy division of 
the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
organization represents approximately 100 of the top 150 US-based financial 
services companies including banks, insurance, consumer finance, and asset 
management firms.

I manage the Technology Cybersecurity Program, a CISO-driven forum to 
investigate emerging technologies; integrate capabilities into member 
operations; and advocate member, sector, cross-sector, and private-public 
collaboration.

While I am aware and on the whole supportive of the significant contributions 
to internet security this important working group has made in the last few 
years I recently learned of a proposed change that would affect many of my 
organization's member institutions:  the deprecation of RSA key exchange.

Deprecation of the RSA key exchange in TLS 1.3 will cause significant problems 
for financial institutions, almost all of whom are running TLS internally and 
have significant, security-critical investments in out-of-band TLS decryption.

Like many enterprises, financial institutions depend upon the ability to 
decrypt TLS traffic to implement data loss protection, intrusion detection and 
prevention, malware detection, packet capture and analysis, and DDoS 
mitigation.  Unlike some other businesses, financial institutions also rely 
upon TLS traffic decryption to implement fraud monitoring and surveillance of 
supervised employees.  The products which support these capabilities will need 
to be replaced or substantially redesigned at significant cost and loss of 
scalability to continue to support the functionality financial institutions and 
their regulators require.

The impact on supervision will be particularly severe.  Financial institutions 
are required by law to store communications of certain employees (including 
broker/dealers) in a form that ensures that they can be retrieved and read in 
case an investigation into improper behavior is initiated.  The regulations 
which require retention of supervised employee communications initially focused 
on physical and electronic mail, but now extend to many other forms of 
communication including instant message, social media, and collaboration 
applications.  All of these communications channels are protected using TLS.

The impact on network diagnostics and troubleshooting will also be serious.  
TLS decryption of network packet traces is required when troubleshooting 
difficult problems in order to follow a transaction through multiple layers of 
infrastructure and isolate the fault domain.   The pervasive visibility offered 
by out-of-band TLS decryption can't be replaced by MITM infrastructure or by 
endpoint diagnostics.  The result of losing this TLS visibility will be 
unacceptable outage times as support groups resort to guesswork on difficult 
problems.

Although TLS 1.3 has been designed to meet the evolving security needs of the 
Internet, it is vital to recognize that TLS is also being run extensively 
inside the firewall by private enterprises, particularly those that are heavily 
regulated.  Furthermore, as more applications move off of the desktop and into 
web browsers and mobile applications, dependence on TLS is increasing.

Eventually, either security vulnerabilities in TLS 1.2, deprecation of TLS 1.2 
by major browser vendors, or changes to regulatory standards will force these 
enterprises - including financial institutions - to upgrade to TLS 1.3.  It is 
vital to financial 

Re: [TLS] Industry Concerns about TLS 1.3

[BITS Security]

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:e...@rtfm.com] 
Sent: Friday, September 23, 2016 4:43 PM
To: BITS Security 
Cc: Salz, Rich ; nalini.elk...@insidethestack.com; 
tls@ietf.org
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  
wrote:
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:tls-boun...@ietf.org] On Behalf Of Salz, Rich
Sent: Friday, September 23, 2016 3:08 PM
To: nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

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

Oxygen, coke, and cookies too.

--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Peter Gutmann]

Andrei Popov  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.
 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

[Judson Wilson]

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



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

On Mon, Sep 26, 2016 at 5:20 PM, Viktor Dukhovni 
wrote:

>
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla  wrote:
> >
> > 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.
> >
> > 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.
>
> 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.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls