Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

s 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 Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 * BITS Sec

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

Re: [TLS] Industry Concerns about TLS 1.3

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 20

Re: [TLS] Industry Concerns about TLS 1.3

> > > From: Tony Arcieri [mailto:basc...@gmail.com] > Sent: Tuesday, September 27, 2016 4:17 PM > To: BITS Security > Cc: Peter Bowen ; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > On Mon, Sep 26, 2016 at 12:01 PM, BITS Security < bitssec

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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 Cc: Peter Bowen ; tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Mon, Sep 26, 2016 at 12:01 PM, BITS Security

Re: [TLS] Industry Concerns about TLS 1.3

ress 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 Cc: tls@ietf.org Subject: Re: [TLS] Industry

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

2:24 PM > To: BITS Security > Cc: Eric Rescorla ; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote: > > Hi Eric--Thank you for the prompt. > > > > Our requirements are for th

Re: [TLS] Industry Concerns about TLS 1.3

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 for

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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 te

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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'

Re: [TLS] Industry Concerns about TLS 1.3

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 thi

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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. The last major backdoored encryption protocol I can remember came from

Re: [TLS] Industry Concerns about TLS 1.3

Please keep aiming for forward-secrecy. (Just in case my wording has been unclear.) From: Yoav Nir [mailto:ynir.i...@gmail.com] Sent: Wednesday, September 28, 2016 1:51 PM >On 28 Sep 2016, at 7:16 PM, Dan Brown wrote:   >> I know little about existing products

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

___ From: TLS [tls-boun...@ietf.org] on behalf of Hovav Shacham [ho...@cs.ucsd.edu] Sent: Sunday, September 25, 2016 9:19 PM To: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael mailto:mackerm...@bcbsm.com>> wrote: Aga

Re: [TLS] Industry Concerns about TLS 1.3

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 actual

Re: [TLS] Industry Concerns about TLS 1.3

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 wor

Re: [TLS] Industry Concerns about TLS 1.3

-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

Re: [TLS] Industry Concerns about TLS 1.3

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 s

Re: [TLS] Industry Concerns about TLS 1.3

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 te

Re: [TLS] Industry Concerns about TLS 1.3

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 _

Re: [TLS] Industry Concerns about TLS 1.3

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 c

Re: [TLS] Industry Concerns about TLS 1.3

and-early-tls> Thanks, Ron From: TLS on behalf of Tony Arcieri Date: Tuesday, September 27, 2016 at 1:17 PM To: BITS Security Cc: Jeffrey Walton Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Mon, Sep 26, 2016 at 12:01 PM, BITS Security mailto:bitssecur...@fsroundtable.org>> wr

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

Re: [TLS] Industry Concerns about TLS 1.3

Cc: Eric Rescorla ; tls@ietf.org > Subject: Re: [TLS] Industry Concerns about TLS 1.3 > > On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote: >> Hi Eric--Thank you for the prompt. >> >> Our requirements are for the same capabilities we have today with TLS >> 1.

Re: [TLS] Industry Concerns about TLS 1.3

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

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 potentia

Re: [TLS] Industry Concerns about TLS 1.3

@welho.com] Sent: Tuesday, September 27, 2016 2:24 PM To: BITS Security Cc: Eric Rescorla ; tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Tue, Sep 27, 2016 at 06:07:28PM +, BITS Security wrote: > Hi Eric--Thank you for the prompt. > > Our requirements are for th

Re: [TLS] Industry Concerns about TLS 1.3

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

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

Re: [TLS] Industry Concerns about TLS 1.3

this to our attention. - Andrew From: hugok...@gmail.com [mailto:hugok...@gmail.com] On Behalf Of Hugo Krawczyk Sent: Thursday, September 22, 2016 7:41 PM To: BITS Security Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 If the problem is the use of forward secrecy then

Re: [TLS] Industry Concerns about TLS 1.3

PM To: BITS Security Cc: Salz, Rich ; nalini.elk...@insidethestack.com; tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 Andrew, What would probably be most helpful here would be if you tried to describe what you think your requirements are in some sort of protocol-neutral

Re: [TLS] Industry Concerns about TLS 1.3

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 t

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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 re

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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 abou

Re: [TLS] Industry Concerns about TLS 1.3

hese problems? > It would be very interesting to get the network diagnostic and operations > people (rather than the architects) of the above companies involved in this > conversation. > Also, you know, companies don't really enjoy spending money on network > diagnostic produc

Re: [TLS] Industry Concerns about TLS 1.3

nal Message- From: Bill Frantz [mailto:fra...@pwpconsult.com] Sent: Friday, September 23, 2016 9:31 PM To: BITS Security Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On 9/23/16 at 2:24 PM, bitssecur...@fsroundtable.org (BITS Security) wrote: >But general-purpose messag

Re: [TLS] Industry Concerns about TLS 1.3

atory 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 Cc: Yaron Sheffer ; tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 O

Re: [TLS] Industry Concerns about TLS 1.3

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 suc

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

Original Message- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Saturday, September 24, 2016 10:10 PM > To: Ackermann, Michael ; Pawel Jakub Dawidek < > p.dawi...@wheelsystems.com>; tls@ietf.org > Subject: RE: [TLS] Industry Concerns about TLS 1.3 > > > This la

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

needs of others. You can use static ephemeral shares on the server side if you want. Is that good enough? You can do what Brian Sniffen described above, and you have 1.5 decades to shift or so. > > -Original Message- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Saturd

Re: [TLS] Industry Concerns about TLS 1.3

Sent: Saturday, September 24, 2016 10:10 PM To: Ackermann, Michael ; Pawel Jakub Dawidek ; 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

Re: [TLS] Industry Concerns about TLS 1.3

would be very interesting to get the network diagnostic and operations > people (rather than the architects) of the above companies involved in this > conversation. > Also, you know, companies don't really enjoy spending money on network > diagnostic products which might be co

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

Re: [TLS] Industry Concerns about TLS 1.3

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 affe

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

t; Sent: Friday, September 23, 2016 11:44 AM > To: Ackermann, Michael > 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 > wrote: >> I am not sure I understand what your reply mea

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

> we need a better option than TLS 1.2 that will, > perhaps sooner than we might expect, be deprecated. Why? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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 t

Re: [TLS] Industry Concerns about TLS 1.3

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 n

Re: [TLS] Industry Concerns about TLS 1.3

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 t

Re: [TLS] Industry Concerns about TLS 1.3

in Liu [mailto:xiaoyi...@outlook.com] Sent: Friday, September 23, 2016 5:00 PM To: BITS Security ; Salz, Rich ; 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", b

Re: [TLS] Industry Concerns about TLS 1.3

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 > Cc: tls@ietf.org > Su

Re: [TLS] Industry Concerns about TLS 1.3

dd [mailto:watsonbl...@gmail.com] Sent: Thursday, September 22, 2016 3:06 PM To: BITS Security Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Thu, Sep 22, 2016 at 10:19 AM, BITS Security wrote: > To: IETF TLS 1.3 Working Group Members > > My name is Andrew K

Re: [TLS] Industry Concerns about TLS 1.3

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 d

Re: [TLS] Industry Concerns about TLS 1.3

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 ; Watson Ladd ; Ackermann, Michael Cc: tls@ietf.org Subject: Re: [TLS] Industry Con

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

> 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

Re: [TLS] Industry Concerns about TLS 1.3

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 abo

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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 str

Re: [TLS] Industry Concerns about TLS 1.3

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 Con

Re: [TLS] Industry Concerns about TLS 1.3

> Look, pretty much the entire world is being spied on by national-scale > adversaries who are recording all traffic for eventual decryption and > correlation. *Almost everyone* is having their traffic surveilled. The > problems of debugging a set of enterprise apps doesn’t amount to a hill of

Re: [TLS] Industry Concerns about TLS 1.3

able 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 Cc: tls@ietf.org Subject: Re: [TLS] Industry Concerns about

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 an

Re: [TLS] Industry Concerns about TLS 1.3

essage- > From: Watson Ladd [mailto:watsonbl...@gmail.com] > Sent: Friday, September 23, 2016 11:44 AM > To: Ackermann, Michael > 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 >

Re: [TLS] Industry Concerns about TLS 1.3

F), 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 > Cc: BITS Security ; tls@ietf.org > Subject: Re: [TLS]

Re: [TLS] Industry Concerns about TLS 1.3

ginal Message- From: Watson Ladd [mailto:watsonbl...@gmail.com] Sent: Friday, September 23, 2016 11:44 AM To: Ackermann, Michael 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 wrote: > I am no

Re: [TLS] Industry Concerns about TLS 1.3

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 >

Re: [TLS] Industry Concerns about TLS 1.3

Walton [mailto:noloa...@gmail.com] Sent: Friday, September 23, 2016 10:55 AM To: Ackermann, Michael Cc: BITS Security ; tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael wrote: > From the perspective an Enterprise that runs the

Re: [TLS] Industry Concerns about TLS 1.3

: 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

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"

Re: [TLS] Industry Concerns about TLS 1.3

y, September 23, 2016 4:06 AM To: Yuhong Bao ; BITS Security ; 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 debug

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

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 d

Re: [TLS] Industry Concerns about TLS 1.3

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 ca

Re: [TLS] Industry Concerns about TLS 1.3

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 k

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

Re: [TLS] Industry Concerns about TLS 1.3

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

  1   2   >