Re: [TLS] Breaking into TLS to protect customers

Hi, Rich. You are conflating customers and users. The customer that may be protected by breaking TLS in a bank’s server farm is the bank itself. An IPS system with visibility into the traffic may detect bots that are there to steal data or mine cryptocurrencies or whatever. If the customers

Re: [TLS] TLS interception technologies that can be used with TLS 1.3

At the risk of stating the obvious, it’s because server owners want to use the same OpenSSL, NSS, SChannel, or whatever you call the Java library that everybody else uses. They’re all widely used, actively maintained, and essentially free. None of these libraries support any of this

Re: [TLS] Breaking into TLS to protect customers

Are we going to discuss draft-fenter ad hoc, or we'll start a new thread dedicated to that? Because I strongly believe I also have some suggestions for that draft. ср, 14 мар. 2018 г., 23:30 Salz, Rich : > Some on this list have said that they need to break into TLS in order to

[TLS] Breaking into TLS to protect customers

Some on this list have said that they need to break into TLS in order to protect customers. The thing customers seem to need the most protection is having their personal data stolen. It seems to happen with amazing and disappointing regularity on astounding scales. Some examples include *

Re: [TLS] TLS@IETF101 Agenda Posted

* I think the core of the discussion is that no matter how many times I say that enterprises are trying to protect their customers, you do not consider that a valid use case. Can you point to a section in the Fenter draft that shows how customers are being protected? I could not find it.

Re: [TLS] TLS@IETF101 Agenda Posted

14 Mar. 2018 г., 22:32 Ralph Droms : > > On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov > wrote: > > 13 Mar. 2018 г., 18:38 Ted Lemon : > >> One strategy that's very effective for overcoming resistance to bad ideas >> is to keep

Re: [TLS] TLS@IETF101 Agenda Posted

> On Mar 13, 2018, at 7:45 PM, Artyom Gavrichenkov wrote: > > 13 Mar. 2018 г., 18:38 Ted Lemon >: > One strategy that's very effective for overcoming resistance to bad ideas is > to keep pushing the idea until nobody who's

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:16, Stephen Farrell wrote: > Of course some people who are used to MitMing connections will > have problems and will have to change. I got an offlist message correcting me about the above. I do agree that it's odd to describe post-facto decryption of a TLS session that used RSA

[TLS] TLS interception technologies that can be used with TLS 1.3

One can either use a static DH share, save the ephemerals on the servers and export them, or log all the data on the servers. These options don't require any change to the wire protocol: they just require vendors supporting them. Why don't they meet the needs cited? Sincerely, Watson

Re: [TLS] TLS@IETF101 Agenda Posted

a) Nalini, I haven't posted anything even slightly close to the examples of offending messages you've just written. b) Is this the only message of mine that deserves a response? 14 Mar. 2018 г., 19:00 nalini elkins : > >>One strategy that's very effective for overcoming

Re: [TLS] TLS@IETF101 Agenda Posted

On 15/03/18 00:05, nalini elkins wrote: > There is no question of a smokey back room. I'm sorry to disagree so bluntly, but while I was an AD some of the people involved here requested that I meet them in private to discuss this topic before it had been raised on the list, and without telling

Re: [TLS] TLS@IETF101 Agenda Posted

> If your consortium want a multi-party security protocol that does not affect > other folks' security as you seem to claim, then that is the obvious route to > explore. +1. It seems that this is at the core of the request. In which case the proper solution is to define this multi-party

Re: [TLS] TLS@IETF101 Agenda Posted

Stephen, More on other points later. I am getting pretty tired as am jet lagged. >I am just fine with talking openly on the mailing list, as >per IETF processes. I see no benefit in smokey back room >discussions here at all, and only downsides to such. You know, this issue of side or quiet

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:32, nalini elkins wrote: > But, it is a very difficult issue. If I can use a different analogy, if > the City of Monterey built a new sewer system and told me that to connect > to it, I had to build a new house, I would scream! Analogies cannot be used to draw conclusions,

Re: [TLS] TLS@IETF101 Agenda Posted

>>Enterprises value security and privacy. They have a different job to do. What they are trying to do is to protect against leakage of data, do fraud monitoring, protect against malware and many other things. When this gets into the medical arena, >>it can even be lives. I don't even see

Re: [TLS] TLS@IETF101 Agenda Posted

- >The simple explanation is that people think they will have serious issues with TLS1.3 and actually, TLS1.2 when it is DH only. >They have a problem with a protocol that doesn’t use static-RSA key exchange. And they would rather not pay for a solution to that problem. I would not

Re: [TLS] TLS@IETF101 Agenda Posted

* The simple explanation is that people think they will have serious issues with TLS1.3 and actually, TLS1.2 when it is DH only. They have a problem with a protocol that doesn’t use static-RSA key exchange. And they would rather not pay for a solution to that problem.

Re: [TLS] TLS@IETF101 Agenda Posted

Stephen, >So it doesn't really help the discussion to claim that >such-and-such a (set of person(s) is/are good actors - we do >assume that, but also that there are others who would like >the same changes to happen who do not share the IETF's goals >of making Internet security better as far as we

Re: [TLS] TLS@IETF101 Agenda Posted

On Wed, Mar 14, 2018 at 7:17 PM, nalini elkins wrote: > >>- > Nalini, why don't you (the consortium) define the standard, then? >> >> >> >> > Indeed, if a “TLS13-visibility” standard has to be defined, it would >> make sense for the consortium (rather than the TLS

Re: [TLS] TLS@IETF101 Agenda Posted

> > >- > Nalini, why don't you (the consortium) define the standard, then? > > > > > Indeed, if a “TLS13-visibility” standard has to be defined, it would > make sense for the consortium (rather than the TLS WG) to define it. > > > > I completely disagree. Here is why I would not prefer that

Re: [TLS] TLS@IETF101 Agenda Posted

On 14/03/18 23:00, nalini elkins wrote: > The simple explanation is that people think they will have serious > issues with TLS1.3 and actually, TLS1.2 when it is DH only. Of course some people who are used to MitMing connections will have problems and will have to change. But that does not

Re: [TLS] TLS@IETF101 Agenda Posted

On Wed, Mar 14, 2018 at 6:52 PM, nalini elkins wrote: > > All, > > In London now & back on email: > > >- >> Nalini, why don't you (the consortium) define the standard, then? > > > > > Indeed, if a “TLS13-visibility” standard has to be defined, it would > make sense

Re: [TLS] TLS@IETF101 Agenda Posted

> > >>One strategy that's very effective for overcoming resistance to bad > ideas is to keep pushing the idea until nobody who's resisting it can > afford to continue doing so. > >There's a name for that tactics, it's called "consensus by exhaustion". (On the recent GNSO meeting this was briefly

Re: [TLS] TLS@IETF101 Agenda Posted

All, In London now & back on email: - >> Nalini, why don't you (the consortium) define the standard, then? > Indeed, if a “TLS13-visibility” standard has to be defined, it would make sense for the consortium (rather than the TLS WG) to define it. I completely disagree. Here is why I

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

Hi Rich (and Tony Rutkowski == hot_middlebox I assume?) On 14/03/18 22:17, Salz, Rich wrote: > * The requirements for visibility exist in an array of regulated > environments worldwide. It is one of the presentation areas in the Hot > Middlebox Workshop. >

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

* The requirements for visibility exist in an array of regulated environments worldwide. It is one of the presentation areas in the Hot Middlebox Workshop.

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

The requirements for visibility exist in an array of regulated environments worldwide. It is one of the presentation areas in the Hot Middlebox Workshop. http://www.etsi.org/etsi-security-week-2018/middlebox-security?tab=1 The Middlebox Hackathon site is also now public so everyone can

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

On Wed, Mar 14, 2018 at 12:46:25PM +0100, Hubert Kario wrote: > On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote: > > It seems like we get ourselves in trouble by allowing multiple > > external PSKs to be present. If we allowed at most one external > > PSK in a given ClientHello,

Re: [TLS] TLS@IETF101 Agenda Posted

On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley wrote: > Second, using > TLS1.2 does not technically address the issue. If the client were to > exclusively offer DHE-based ciphersuites, then the visibility techniques > that have been used in the past are thwarted. I expect

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

> On Mar 14, 2018, at 9:42 AM, Salz, Rich wrote: > > >> So aside from enabling MitM, this also enables session resumption by >the decryption service, something that the security considerations >neglects to include in its list. > > So I think this is an important

Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

> On Mar 14, 2018, at 4:48 AM, Martin Thomson wrote: > > On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley wrote: >> Nick Sullivan summarized >> four concerns with that approach. See >>

Re: [TLS] TLS@IETF101 Agenda Posted

>while sure, both TLS 1.0 and TLS 1.2 likely will be removed from those > afore- mentioned libraries at _some_ point, it is disingenuous to suggest it will happen in a matter of just few years, especially for the latter of the two protocols Absolutely true!

Re: [TLS] TLS@IETF101 Agenda Posted

On Wednesday, 14 March 2018 19:53:21 CET Russ Housley wrote: > > On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > > > On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote: > >> Ted: > >>> There's an easy way to do this, although as a sometime bank security > >>> geek

Re: [TLS] TLS@IETF101 Agenda Posted

Perhaps this would be a good time to put in a plug for additional funding for openssl et al... On Mar 14, 2018 14:53, "Russ Housley" wrote: > > > On Mar 14, 2018, at 8:39 AM, Hubert Kario wrote: > > > > On Tuesday, 13 March 2018 23:16:47 CET Russ

Re: [TLS] TLS@IETF101 Agenda Posted

On Mar 13, 2018, at 11:49 PM, Russ Housley wrote: > I was trying to separate these two cases. If the TLS session is terminated > at a load balancer, then the client within the load balancer is (as Ted says) > under control of the operator. The operator can include any

Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

On Wednesday, 14 March 2018 03:02:10 CET Benjamin Kaduk wrote: > It seems like we get ourselves in trouble by allowing multiple > external PSKs to be present. If we allowed at most one external > PSK in a given ClientHello, then aborting the handshake on binder > failure would be the correct

Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

Russ, On 14/03/18 03:03, Russ Housley wrote: > Stephen: > >>> I do not know if the TLS WG will want to adopt this approach. I >>> would like to find out. >> >> Did you read the list traffic from Oct/Nov? I have no idea how you >> can be in doubt if you did. It's readily apparent that your

[TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at IETF101)

On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley wrote: > Nick Sullivan summarized > four concerns with that approach. See > https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg > > draft-rhrd-... addresses all four of these concerns. This isn't quite right.