Re: [TLS] Industry Concerns about TLS 1.3

2016-10-18 Thread Ryan Carboni
On Sat, Oct 1, 2016 at 4:23 AM, Peter Gutmann 
wrote:

> Ryan Carboni  writes:
>
> >I've never quite understood what TLS was supposed to be protecting
> against,
> >and whether or not it has done so successfully, or has the potential to
> do so
> >successfully.
>
> It's the Inside-Out Thread Model (also shared by a number of other security
> protocols, it's not just TLS), "our defence is SSL/TLS/IPsec/PKI/…  and our
> threat model is whatever that happens to defend against".  DNSSEC is a
> classic
> example of this, the DNSSEC requirements doc was published *a decade* after
> DNSSEC itself.  Mind you, other protocols are still waiting for their
> requirements doc to be published.  PKIX specifically actively declined to
> consider use cases because heck, this is a standards committee dammit, we
> can't be expected to take into account what people want to do with it.
>
> Mind you, in the absence of any success criteria, no-one can say you've
> failed...
>
> Peter.



It is worth reading this paper apparently from 2010 on reusing ephemeral
keys:

https://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf

Regardless, I can hope the Snowden disclosures will force people into
action.

But please.

Continue to make the internet secure.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-10-05 Thread BITS Security
Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few 
years back that moved Diffie Hellman to the top cipher suite priorities which 
broke security and fraud monitoring, APM reporting, and sniffer troubleshooting 
for a financial services client and at least one other organization in a 
different industry.  

The solution, at the time, was to put the PFS options (choices we will no 
longer in 1.3) at the bottom of the priority list.  I don't know how much of 
this was communicated back to the vendors at the time.  

In retrospect, this could have been seen as the canary in the coalmine... but 
here we are now at least.  

- Andrew 


-Original Message-
From: Florian Weimer [mailto:f...@deneb.enyo.de] 
Sent: Wednesday, October 5, 2016 2:17 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

* BITS Security:

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

We should have already seen this with changing defaults in crypto libraries as 
part of security updates.  That should have broken passive monitoring 
infrastructure, too.

Maybe some of the vendors can shed some light on this problem and tell us if 
they ever have received pushback for rolling out ECDHE-by-default.  (I know 
that some products have few capabilities for centralized policy management, 
which is why defaults matter a lot
there.)

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-10-05 Thread Florian Weimer
* BITS Security:

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

We should have already seen this with changing defaults in crypto
libraries as part of security updates.  That should have broken
passive monitoring infrastructure, too.

Maybe some of the vendors can shed some light on this problem and tell
us if they ever have received pushback for rolling out
ECDHE-by-default.  (I know that some products have few capabilities
for centralized policy management, which is why defaults matter a lot
there.)

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-10-03 Thread Tony Arcieri
On Mon, Oct 3, 2016 at 2:21 PM, BITS Security  wrote:

> If PCI has mandated upgrading TLS because of vulnerabilities, they are
> likely to do it again and in fact have provided strong hints to the market
> where they should be beyond the minimum requirement itself.


This is simply not true. In 2015 the PCI council was pushing for updating
to TLS 1.1+ in short order, but backed off out of "industry concerns"
similar to the ones you are voicing here, and have delayed the mandatory
rollout of TLS 1.1 until 2018.

That's at least two years away.

After that, they will deprecate TLS 1.1. That will probably take at least a
year. So in 2019 (again, pure speculation as to the earliest time this will
possibly happen), TLS 1.2 will be mandatory.

After that, they may deprecate TLS 1.2 if it is demonstrated to be
insecure. There is no reason to suspect at this point that that will even
happen. TLS 1.2 is generally recognized as secure, and the "LTS" profile
should fix whatever low-priority security concerns remain.


> I don't see that the timing really matters because it isn't based on the
> age of the standard, it is based on the standard becoming outdated.


That is absolutely not true. The PCI's motivation for TLS version upgrades
has been real-world security vulnerabilities, and again, it took them 15
years to deprecate TLS 1.0.

There is absolutely no evidence that the PCI council plans on making TLS
1.3 mandatory any time soon, and if we follow a version-a-year cadence
(which they're NOT presently working on, based on the one deprecation data
point we have it's ~3 years per version) it will be 2020 at the earliest
before it happens.

You are asking the IETF to make a serious compromise regarding the security
of the Internet based on *pure speculation*. A minimum degree of due
diligence here would be to first ask the PCI council what their plans for
mandating TLS 1.3 actually are, and if they *actually* give you a date that
scares you, that might be a reason to voice concern so late in the process.

I think what you're proposing is actively harmful to Internet security and
you should be working with the PCI Council, not the IETF, to address your
concerns.

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-10-03 Thread Watson Ladd
>
> If you look at the industry reports like the Verizon PCI Breach and
Compliance Reports, private keys simply aren't being stolen.  Maybe there
is an outlier or two but there certainly isn't a documented trend I can
find.  If you have contravening information to provide I am all ears.

Surely you remember the day when all SWIFT provided devices had to be
replaced thanks to some fun in the random number generators. Then there is
POISON NUT.

The Shadow brokers leak included tools to extract VPN keys from Cisco
routers. TJ Maxx involved breaking WEP.

>
> - Andrew
>
>
>
> From: Tony Arcieri [mailto:basc...@gmail.com]
> Sent: Tuesday, September 27, 2016 4:17 PM
> To: BITS Security <bitssecur...@fsroundtable.org>
> Cc: Peter Bowen <pzbo...@gmail.com>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-10-03 Thread Jeffrey Walton
> PCI requirement providing Intrusion Detection at the entrance to Cardholder 
> Data Environments as well as at critical points inside the Cardholder Data 
> Environment.  Intrusion Detection requires decryption of TLS.  For some 
> large, complex organizations this can be a large number of physical 
> inspection points, more than can be accommodated by MITM.  I understand this 
> may not be a problem for your current environment but others do not have that 
> luxury.
>

This may be less than an ideal requirement.

Malware wants to do three things (with some hand waiving): (1) spread,
(2) collect data, and (3) egress data. I think Step (1) and intrusion
detection is a worthy cause, but not at the cost of breaking the
secure channel.

Perhaps it would be better to focus on (2) and (3). (2) can be tricky
based on how deeply the malware is burrowed in. (3) is much easier
since the malware needs to open a socket.

Policies for (3) are really just whitelist/blacklist approaches. I'm
guessing egress points are wide open at the moment, and the PCI
requirement is fostering blacklists and causing the organization to be
reactive. If the egress points are closed at the organizational
boundary, then the organization is proactive and using a whitelist
approach.

Would it be possible to have the PCI folks re-examine their position
since it seems to be boxing BITS members into something untenable?

Jeff

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-10-03 Thread BITS Security
> 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 PCI has mandated upgrading TLS because of vulnerabilities, they are likely 
to do it again and in fact have provided strong hints to the market where they 
should be beyond the minimum requirement itself.  I don't see that the timing 
really matters because it isn't based on the age of the standard, it is based 
on the standard becoming outdated.  We're trying to get ahead of foreseeable 
problem some will have. 

Further, PCI does not require TLS encryption at all in a private data center, 
at least not technically.  However, in practice they strongly recommend 
segmenting the Cardholder Data Environment, which I suspect most financials 
have done, and many have used TLS as part of their strategy for segmentation 
(encrypted PCI traffic flowing through devices does not bring these devices 
into scope for audit).  So according to current practice, auditors are going to 
require certain levels of TLS in order for our segmenting strategies to work.

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

PCI requirement providing Intrusion Detection at the entrance to Cardholder 
Data Environments as well as at critical points inside the Cardholder Data 
Environment.  Intrusion Detection requires decryption of TLS.  For some large, 
complex organizations this can be a large number of physical inspection points, 
more than can be accommodated by MITM.  I understand this may not be a problem 
for your current environment but others do not have that luxury.

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

We can implore PCI all we want, but if events overtake us, such as the 
introduction of new security risks, we have to be prepared for eventualities 
like TLS 1.3 being the mandate and must be prepared perform IDS/IPS routines at 
scale such an environment.

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

I don't know how this listserv operates in practice but it is this type of 
sophistry that hard boils my eggs to put it politely.  Perhaps this is just the 
regular cost of participation but that would be unfortunate.  

If you look at the industry reports like the Verizon PCI Breach and Compliance 
Reports, private keys simply aren't being stolen.  Maybe there is an outlier or 
two but there certainly isn't a documented trend I can find.  If you have 
contravening information to provide I am all ears. 

- Andrew 



From: Tony Arcieri [mailto:basc...@gmail.com] 
Sent: Tuesday, September 27, 2016 4:17 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Peter Bowen <pzbo...@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-10-03 Thread 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.  

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

We can put private keys in an HSM and implement other processes to protect 
them.  This is what some are doing with RSA today.  If you look at the Verizon 
breach report and other similar resources, breaches from stolen network packets 
and/or stolen private keys is not a discernible trend (though I will cede past 
results don't predict future performance). 

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

We've heard this a different way, for example not every layer of the data 
center would have the same key or that key is always available. I have to admit 
to some ignorance here which is why we want to explore this potential option.  
Even if it works (which it might not as you say) there still is the question of 
if vendors would being willing to support.  

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

Something else important to check on that could undermine this solution.  
Appreciate it.  

- Andrew 




-Original Message-
From: Seth David Schoen [mailto:sch...@eff.org] 
Sent: Tuesday, September 27, 2016 2:30 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

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 als

Re: [TLS] Industry Concerns about TLS 1.3

2016-10-01 Thread Peter Gutmann
Ryan Carboni  writes:

>I've never quite understood what TLS was supposed to be protecting against,
>and whether or not it has done so successfully, or has the potential to do so
>successfully.

It's the Inside-Out Thread Model (also shared by a number of other security
protocols, it's not just TLS), "our defence is SSL/TLS/IPsec/PKI/…  and our
threat model is whatever that happens to defend against".  DNSSEC is a classic
example of this, the DNSSEC requirements doc was published *a decade* after
DNSSEC itself.  Mind you, other protocols are still waiting for their
requirements doc to be published.  PKIX specifically actively declined to
consider use cases because heck, this is a standards committee dammit, we
can't be expected to take into account what people want to do with it.

Mind you, in the absence of any success criteria, no-one can say you've
failed...

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-29 Thread Hannes Tschofenig
Hi Ryan,

people working in the security field know what features TLS provides and
those are highly valued since otherwise it wouldn't be used so widely.

I prefer to finalize the work on TLS 1.3 as planned. There are various
groups successfully working on their implementations and I am looking
forward to a well-attended Hackathon at the next IETF meeting.

Ciao
Hannes


On 09/29/2016 09:01 AM, Ryan Carboni wrote:
> I've never quite understood what TLS was supposed to be protecting
> against, and whether or not it has done so successfully, or has the
> potential to do so successfully.
> 
> Well, I don't think anyone here even knows how to protect a mailing list
> from multi-billion dollar threat actors so...???
> 
> Let me quote RFC 3526: 
> "The
>strengths of the groups defined here are always estimates and there
>are as many methods to estimate them as there are cryptographers."
> 
> But whatever. You people aren't even willing to do what the Germans
> did... twice.
> 
> Personally I think TLS should be scrapped, replaced with a protocol
> without negotiation, replace PKI with trusted notaries
> ( https://en.wikipedia.org/wiki/Convergence_(SSL) ), etc.
> 
> But, no one has been able to program anything correctly, not even
> certificate authorities: 
> 
> https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com
> 
> I'm not paying you people anyway. At least the protocol is theoretically
> secure.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-29 Thread Ryan Carboni
I've never quite understood what TLS was supposed to be protecting against,
and whether or not it has done so successfully, or has the potential to do
so successfully.

Well, I don't think anyone here even knows how to protect a mailing list
from multi-billion dollar threat actors so...???

Let me quote RFC 3526:
"The
   strengths of the groups defined here are always estimates and there
   are as many methods to estimate them as there are cryptographers."

But whatever. You people aren't even willing to do what the Germans did...
twice.

Personally I think TLS should be scrapped, replaced with a protocol without
negotiation, replace PKI with trusted notaries (
https://en.wikipedia.org/wiki/Convergence_(SSL) ), etc.

But, no one has been able to program anything correctly, not even
certificate authorities:

https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com

I'm not paying you people anyway. At least the protocol is theoretically
secure.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Bill Frantz
On 9/28/16 at 4:27 PM, melinda.sh...@nomountain.net (Melinda 
Shore) wrote:



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.


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


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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Tony Arcieri
On Wed, Sep 28, 2016 at 5:49 PM, Melinda Shore  wrote:

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


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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Melinda Shore
On 9/28/16 4:36 PM, Tony Arcieri wrote:
> 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.

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




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Tony Arcieri
On Wed, Sep 28, 2016 at 4:27 PM, Melinda Shore  wrote:

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


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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Melinda Shore
On 9/28/16 3:08 PM, Bill Frantz wrote:
> On 9/28/16 at 2:01 AM, m...@sap.com wrote:
>> I'm sorry, but I'm still violently opposed to the IETF endorsing
>> backdooring of security protocols.
> 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




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Yoav Nir

> On 28 Sep 2016, at 7:16 PM, Dan Brown  wrote:
> 
> 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...

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Martin Rex
Martin Rex wrote:
> Stephen Farrell wrote:
> > 
> > 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:-)
> 
> 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 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.

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Martin Rex
Stephen Farrell wrote:
> 
> 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:-)

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Joachim Strömbergson
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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.
> 
> Okay, in technical terms only, what is the difference?
> 
>> 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  joac...@secworks.se

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIbBAEBCAAGBQJX6466AAoJEF3cfFQkIuyN+xEP+OFOliFsdy8qzTlYFXwEKaHm
CsujoaU/vswzXK6y3MadGn4rVhBjuaA1P4Iu5E1/w8Wlm7B6HOTXqM2iJVCv1bQs
D8iS5JRS9TR3cnXtEDk51V+nYQmDxFBhNILwukVrp8alvvVh/ww21bLxrp9xrLy5
8rfynu6BD2QreVfRGYDjT4rfxU5t+EecwCsxBn1JM/+Uv0/e/cFQVI55dnWm4OWi
WwX7ieRyd/N76VadyHhAV9VFXnpIewBSINyroCfBEHDeiDmYEQcCcIOVjMI6EHp8
T3D/rCZR865G06PO7gxY4IVsS4pbd3lXYyG/+9SSDm/axWJ7FasoaoaqXm19EaCc
p9399BaJss7kLS+1c63axzm7xcdRE1fqJN2oJNlRnD7zv6ycvcg2cbuC5HUKasHx
H9RL7VAry33KP8EGBMPbf8Ep9IfX2l/dtMe1FMuNaTajsXj9vMKi0eOZ5EVPykqZ
fuX9rwMUXafNkWVrVUflxQHU9fY6+5ZkncoEtUUQASlGeL2K9edMdUD0vs5WceHe
HYc4mLdJsi88crwE5/HPQHl8ncZCTwlMTxxyAdySf4uotKPQytnPha1mPrijOUQS
A4KEzIA1BcEFSdMR/3v2Bw8qNLA5HU5fV22NBlS8nYkgdqmmF9nwUTgJ7G2x8zcw
2HBLYpaDWnMyGEcaAv0=
=9iJ/
-END PGP SIGNATURE-

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Martin Rex
Judson Wilson wrote:
> 
> 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.)


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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-28 Thread Hannes Tschofenig
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:
> 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 

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-27 Thread 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

2016-09-27 Thread 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

2016-09-27 Thread 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.<https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls>

Thanks,
Ron

From: TLS <tls-boun...@ietf.org> on behalf of Tony Arcieri <basc...@gmail.com>
Date: Tuesday, September 27, 2016 at 1:17 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Jeffrey Walton <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security 
<bitssecur...@fsroundtable.org<mailto: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



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

2016-09-27 Thread 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

2016-09-27 Thread 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 <bitssecur...@fsroundtable.org>
> Cc: Eric Rescorla <e...@rtfm.com>; 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

2016-09-27 Thread 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

2016-09-27 Thread 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

2016-09-27 Thread 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 <bitssecur...@fsroundtable.org>
Cc: Eric Rescorla <e...@rtfm.com>; 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

2016-09-27 Thread 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

2016-09-27 Thread 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

2016-09-27 Thread 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 <bitssecur...@fsroundtable.org>
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 <bitssecur...@fsroundtable.org> 
wrote:
To:  IETF TLS 1.3 Working Group Members

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

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

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

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

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

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

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

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

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-27 Thread 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 <bitssecur...@fsroundtable.org>
Cc: Salz, Rich <rs...@akamai.com>; 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 <bitssecur...@fsroundtable.org> 
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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-27 Thread 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

2016-09-27 Thread 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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Viktor Dukhovni

> 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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Eric Rescorla
On Mon, Sep 26, 2016 at 4:09 PM, Viktor Dukhovni 
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.

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Viktor Dukhovni

> On Sep 26, 2016, at 3:23 PM, BITS Security  
> wrote:
> 
> 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 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.  

I very much doubt that the APT 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.

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Geoffrey Keating
BITS Security  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.

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Andrei Popov
?  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:tls-boun...@ietf.org] On Behalf Of Xiaoyin Liu
Sent: Monday, September 26, 2016 1:12 PM
To: BITS Security <bitssecur...@fsroundtable.org>; Peter Bowen 
<pzbo...@gmail.com>
Cc: tls@ietf.org
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



From: BITS Security<mailto:bitssecur...@fsroundtable.org>
Sent: Monday, September 26, 2016 3:02 PM
To: Peter Bowen<mailto:pzbo...@gmail.com>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3


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:pzbo...@gmail.com]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security 
<bitssecur...@fsroundtable.org<mailto:bitssecur...@fsroundtable.org>>
Cc: Yaron Sheffer <yaronf.i...@gmail.com<mailto:yaronf.i...@gmail.com>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security 
<bitssecur...@fsroundtable.org<mailto:bitssecur...@fsroundtable.org>> 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
___
TLS mailing list
TLS@ietf.org<mailto: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

2016-09-26 Thread Xiaoyin Liu
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:bitssecur...@fsroundtable.org>
Sent: Monday, September 26, 2016 3:02 PM
To: Peter Bowen<mailto:pzbo...@gmail.com>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3



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:pzbo...@gmail.com]
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Yaron Sheffer <yaronf.i...@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 2:10 PM, BITS Security <bitssecur...@fsroundtable.org> 
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
___
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

2016-09-26 Thread BITS Security
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:tls-boun...@ietf.org] On Behalf Of Brian Sniffen
Sent: Saturday, September 24, 2016 11:31 PM
To: nalini.elk...@insidethestack.com; Watson Ladd <watsonbl...@gmail.com>; 
Ackermann, Michael <mackerm...@bcbsm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

nalini.elk...@insidethestack.com writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>
>>> 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.

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).
> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -Original Message-
>> From: Jeffrey Walton [mailto:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <mackerm...@bcbsm.com>
>> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
>> wrote:
>>> 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).
>>
>> 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
>>
>>
>> The information contained in this communication is highly confidential a

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread BITS Security
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:pzbo...@gmail.com] 
Sent: Friday, September 23, 2016 7:18 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: Yaron Sheffer <yaronf.i...@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Martin Rex
Pawel Jakub Dawidek wrote:
> 
> 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.

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-26 Thread Pascal Urien
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 <mackerm...@bcbsm.com>:

> 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:rs...@akamai.com]
> Sent: Saturday, September 24, 2016 10:10 PM
> To: Ackermann, Michael <mackerm...@bcbsm.com>; Pawel Jakub Dawidek <
> p.dawi...@wheelsystems.com>; tls@ietf.org
> 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).
>
> 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.
>
>
>
>
> 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.
>
> ___
> 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

2016-09-26 Thread Martin Rex
Thijs van Dijk wrote:
> 
> 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).

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-25 Thread Hovav Shacham
On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael 
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-24 Thread Brian Sniffen
nalini.elk...@insidethestack.com writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>
>>> 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.

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).
> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -Original Message-----
>> From: Jeffrey Walton [mailto:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <mackerm...@bcbsm.com>
>> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
>> wrote:
>>> 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).
>>
>> 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
>>
>>
>> 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.
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> -- 
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-24 Thread Ilari Liusvaara
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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-24 Thread Ackermann, Michael
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:tls-boun...@ietf.org] On Behalf Of Pawel Jakub Dawidek
Sent: Saturday, September 24, 2016 2:54 AM
To: tls@ietf.org
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.

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 For

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Salz, Rich
> we need a better option than TLS 1.2 that will,
> perhaps sooner than we might expect, be deprecated.

Why?

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Bill Frantz
On 9/23/16 at 2:24 PM, bitssecur...@fsroundtable.org (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


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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Peter Bowen
On Fri, Sep 23, 2016 at 2:10 PM, BITS Security
 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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Adam Caudill
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
a...@adamcaudill.com
http://adamcaudill.com/


> On Sep 23, 2016, at 5:34 PM, BITS Security  
> wrote:
> 
>> 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
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Jeffrey Walton
On Fri, Sep 23, 2016 at 5:34 PM, BITS Security
 wrote:
>> 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.

Its not the first time C 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

Jeff

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread BITS Security
> 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:xiaoyi...@outlook.com] 
Sent: Friday, September 23, 2016 5:00 PM
To: BITS Security <bitssecur...@fsroundtable.org>; Salz, Rich 
<rs...@akamai.com>; nalini.elk...@insidethestack.com
Cc: tls@ietf.org
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; nalini.elk...@insidethestack.com
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3
 
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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Watson Ladd
  There is no scalable way to intercept VM to VM TLS that 
> never leaves the virtual server.

The word scalable has a meaning. MITM scales linearly.
> --Andrew
>
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Watson Ladd
> Sent: Friday, September 23, 2016 11:44 AM
> To: Ackermann, Michael <mackerm...@bcbsm.com>
> Cc: tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
> wrote:
>>  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 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?
>
>>
>> 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?
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -Original Message-
>> From: Jeffrey Walton [mailto:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael <mackerm...@bcbsm.com>
>> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
>> wrote:
>>> 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).
>>
>> 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
>>
>>
>> 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.
>> ___
>> 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



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

2016-09-23 Thread BITS Security
> 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 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.   


> And firing isn't enough of a threat to get people to behave when it
> 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:watsonbl...@gmail.com] 
Sent: Thursday, September 22, 2016 3:06 PM
To: BITS Security <bitssecur...@fsroundtable.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <bitssecur...@fsroundtable.org> 
wrote:
> To:  IETF TLS 1.3 Working Group Members
>
> My name is Andrew Kennedy and I work at BITS, the technology policy division 
> of the Financial Services Roundtable (http://www.fsroundtable.org/bits).  My 
> organization represents approximately 100 of the top 150 US-based financial 
> services companies including banks, insurance, consumer finance, and asset 
> management firms.
>
> I manage the Technology Cybersecurity Program, a CISO-driven forum to 
> investigate emerging technologies; integrate capabilities into member 
> operations; and advocate member, sector, cross-sector, and private-public 
> collaboration.
>
> While I am aware and on the whole supportive of the significant contributions 
> to internet security this important working group has made in the last few 
> years I recently learned of a proposed change that would affect many of my 
> organization's member institutions:  the deprecation of RSA key exchange.

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.

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Stephen Farrell

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.




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

2016-09-23 Thread BITS Security
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:yaronf.i...@gmail.com] 
Sent: Friday, September 23, 2016 3:52 PM
To: BITS Security <bitssecur...@fsroundtable.org>; Watson Ladd 
<watsonbl...@gmail.com>; Ackermann, Michael <mackerm...@bcbsm.com>
Cc: tls@ietf.org
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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Xiaoyin Liu
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:bitssecur...@fsroundtable.org>
Sent: Friday, September 23, 2016 4:31 PM
To: Salz, Rich<mailto:rs...@akamai.com>; 
nalini.elk...@insidethestack.com<mailto:nalini.elk...@insidethestack.com>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3



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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Salz, Rich
> What is happening from our perspective is choice is being removed and an
> 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: richs...@jabber.at Twitter: RichSalz


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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Eric Rescorla
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 <
bitssecur...@fsroundtable.org> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Yoav Nir

> On 23 Sep 2016, at 10:08 PM, Salz, Rich  wrote:
> 
> 
> 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. 

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread BITS Security
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

2016-09-23 Thread Ilari Liusvaara
On Thu, Sep 22, 2016 at 05:19:48PM +, BITS Security wrote:
> To:  IETF TLS 1.3 Working Group Members
>
> 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. 

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Tony Arcieri
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.

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security <
bitssecur...@fsroundtable.org> wrote:

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

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.

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.


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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Yaron Sheffer

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?


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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Jeffrey Walton
> 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.
>

+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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread BITS Security
> 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?

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


-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Watson Ladd
Sent: Friday, September 23, 2016 11:44 AM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
wrote:
>  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 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?

>
> What I am saying,  in relation to your "Delivering a stable product"  comment 
> is that over 

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Salz, Rich

> 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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Eric Rescorla
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 <mackerm...@bcbsm.com>
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.
>
> -Original Message-
> From: Watson Ladd [mailto:watsonbl...@gmail.com]
> Sent: Friday, September 23, 2016 11:44 AM
> To: Ackermann, Michael <mackerm...@bcbsm.com>
> Cc: noloa...@gmail.com; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <mackerm...@bcbsm.com>
> wrote:
> >  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 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?
>
> >
> > 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?
> >
> > Thanks
> >
> > Mike
> >
> >
> >
> > -Original Message-
> > From: Jeffrey Walton [mailto:noloa...@gmail.com]
> > Sent: Friday, September 23, 2016 10:55 AM
> > To: Ackermann, Michael <mackerm...@bcbsm.com>
> > Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
> > Subject: Re: [TLS] Industry Concerns about TLS 1.3
> >
> > On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <
> mackerm...@bcbsm.com> wrote:
> >> 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).
> >
> > 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
> thin

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Ackermann, Michael
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:watsonbl...@gmail.com] 
Sent: Friday, September 23, 2016 11:44 AM
To: Ackermann, Michael <mackerm...@bcbsm.com>
Cc: noloa...@gmail.com; tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
wrote:
>  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 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?

>
> 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?
>
> Thanks
>
> Mike
>
>
>
> -Original Message-
> From: Jeffrey Walton [mailto:noloa...@gmail.com]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Ackermann, Michael <mackerm...@bcbsm.com>
> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
> wrote:
>> 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).
>
> 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
>
>
> 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.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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


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 or

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Watson Ladd
On Fri, Sep 23, 2016 at 8:31 AM, Ackermann, Michael
<mackerm...@bcbsm.com> wrote:
>  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 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?

>
> 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?
>
> Thanks
>
> Mike
>
>
>
> -Original Message-
> From: Jeffrey Walton [mailto:noloa...@gmail.com]
> Sent: Friday, September 23, 2016 10:55 AM
> To: Ackermann, Michael <mackerm...@bcbsm.com>
> Cc: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>
> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael <mackerm...@bcbsm.com> 
> wrote:
>> 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).
>
> 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
>
>
> 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.
> ___
> 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

2016-09-23 Thread Dan Brown
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:tls-boun...@ietf.org] On Behalf Of Hugo Krawczyk
Sent: Thursday, September 22, 2016 7:41 PM
To: BITS Security <bitssecur...@fsroundtable.org>
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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Jeffrey Walton
On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael
 wrote:
> 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).

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Ackermann, Michael
>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:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
Sent: Friday, September 23, 2016 4:06 AM
To: Yuhong Bao <yuhongbao_...@hotmail.com>; BITS Security 
<bitssecur...@fsroundtable.org>; tls@ietf.org
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.

> 
> 
> From: TLS <tls-boun...@ietf.org> on behalf of BITS Security 
> <bitssecur...@fsroundtable.org>
> Sent: Thursday, September 22, 2016 10:19:48 AM
> To: tls@ietf.org
> Subject: [TLS] Industry Concerns about TLS 1.3
> 
> 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 desk

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread nalini.elkins



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.
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: TLS <tls-boun...@ietf.org> on behalf of BITS Security 
> <bitssecur...@fsroundtable.org>
> Sent: Thursday, September 22, 2016 10:19:48 AM
> To: tls@ietf.org
> Subject: [TLS] Industry Concerns about TLS 1.3
> 
> 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 

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Stephen Farrell


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.

> 
> 
> From: TLS <tls-boun...@ietf.org> on behalf of BITS Security 
> <bitssecur...@fsroundtable.org>
> Sent: Thursday, September 22, 2016 10:19:48 AM
> To: tls@ietf.org
> Subject: [TLS] Industry Concerns about TLS 1.3
> 
> 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 no

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-23 Thread Thijs van Dijk
On 23 September 2016 at 04:04, Colm MacCárthaigh  wrote:

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

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Eric Rescorla
On Thu, Sep 22, 2016 at 8:53 PM, Geoffrey Keating  wrote:

> Ryan Carboni  writes:
>
> > in the internet of things, DH is actually
> > less secure than normal public key exchange. Servers are more likely to
> > have entropy than embedded devices.
>
> I think that's backwards; in a 'normal' public key exchange, it is the
> client that generates the secret key, the server contributes no
> randomness.
>

Nit: no private randomness. It provides freshness in the form of
ServerRandom and in
TLS that's specified as random.

-Ekr


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

2016-09-22 Thread Geoffrey Keating
Ryan Carboni  writes:

> in the internet of things, DH is actually
> less secure than normal public key exchange. Servers are more likely to
> have entropy than embedded devices.

I think that's backwards; in a 'normal' public key exchange, it is the
client that generates the secret key, the server contributes no
randomness.

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Colm MacCárthaigh
On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk 
wrote:

> On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh 
> wrote:
>
>> On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk 
>> wrote:
>>
>>> 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.
>>>
>>
>> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Colm MacCárthaigh
On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk 
wrote:

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Andrei Popov
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:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 1:58 PM
To: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org; Andrei Popov 
<andrei.po...@microsoft.com>
Subject: Re: Industry Concerns about TLS 1.3


Adding Andrei Popov.


From: BITS Security 
<bitssecur...@fsroundtable.org<mailto:bitssecur...@fsroundtable.org>>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; tls@ietf.org<mailto:tls@ietf.org>
Subject: RE: Industry Concerns about TLS 1.3

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:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security 
<bitssecur...@fsroundtable.org<mailto:bitssecur...@fsroundtable.org>>; 
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: Industry Concerns about TLS 1.3

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


From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> on behalf of BITS 
Security <bitssecur...@fsroundtable.org<mailto:bitssecur...@fsroundtable.org>>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] Industry Concerns about TLS 1.3

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 wi

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Yuhong Bao
Adding Andrei Popov.


From: BITS Security <bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 1:13:45 PM
To: Yuhong Bao; tls@ietf.org
Subject: RE: Industry Concerns about TLS 1.3

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:yuhongbao_...@hotmail.com]
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
Subject: Re: Industry Concerns about TLS 1.3

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


From: TLS <tls-boun...@ietf.org> on behalf of BITS Security 
<bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: tls@ietf.org
Subject: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Yoav Nir
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  
> wrote:



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

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

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

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread BITS Security
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:yuhongbao_...@hotmail.com] 
Sent: Thursday, September 22, 2016 2:36 PM
To: BITS Security <bitssecur...@fsroundtable.org>; tls@ietf.org
Subject: Re: Industry Concerns about TLS 1.3

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


From: TLS <tls-boun...@ietf.org> on behalf of BITS Security 
<bitssecur...@fsroundtable.org>
Sent: Thursday, September 22, 2016 10:19:48 AM
To: tls@ietf.org
Subject: [TLS] Industry Concerns about TLS 1.3 
 
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 cha

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Dave Garrett
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:

On Thursday, September 22, 2016 01:19:48 pm BITS Security wrote:
> 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.

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

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Salz, Rich
+1 to what Kenny said.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz

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


Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Kyle Rose
On Thu, Sep 22, 2016 at 1:19 PM, BITS Security <
bitssecur...@fsroundtable.org> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread Watson Ladd
On Thu, Sep 22, 2016 at 10:19 AM, 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.

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.

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

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

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.

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

[TLS] Industry Concerns about TLS 1.3

2016-09-22 Thread BITS Security
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