Re: [TLS] TLS@IETF101 Agenda Posted

Doesn’t IETF have a liaison process that is used to work with other standards bodies? And the bigger question, since the ask is essentially for a multi-party security protocol: Is TLS WG the right place to discuss this? Cheers, Andrei From: TLS On Behalf Of Russ Housley

Re: [TLS] Breaking into TLS to protect customers

On Thu, Mar 15, 2018 at 12:58 PM, Carl Mehner wrote: > > > On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty > wrote: >> I think what Yoav is referring to by detecting BOTS within the >> network, is really so called advance persistent threat (APT)

Re: [TLS] Breaking into TLS to protect customers

On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > I think what Yoav is referring to by detecting BOTS within the > network, is really so called advance persistent threat (APT) actors > that are moving around the internal network leveraging existing

Re: [TLS] Breaking into TLS to protect customers

Am 15.03.2018 um 17:58 schrieb Carl Mehner: On Thu, Mar 15, 2018 at 9:59 AM, Kathleen Moriarty > wrote: > I think what Yoav is referring to by detecting BOTS within the > network, is really so called advance

Re: [TLS] Breaking into TLS to protect customers

> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue wrote: > > I fail to see how the current draft can be used to provide visibility to an > IPS system in order to detect bots that are inside the bank… > > On the one hand, the bot would never opt-in for visibility if it’s

Re: [TLS] TLS@IETF101 Agenda Posted

Russ, On 15/03/18 17:29, Russ Housley 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 WG) to >> define it. > > In fact, my mistake

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

This is what OpenSSL provides: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

So what’s the flag in openssl.conf that makes it generate a file with all the keys? There isn’t one. I guess the presumption is that if there was an RFC it would be easier to get the powers that be to make it happen. It likely needs to be in the main branch to be ubiquitous, because many

Re: [TLS] Breaking into TLS to protect customers

> -Mensaje original- > De: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] > Enviado el: jueves, 15 de marzo de 2018 18:42 > Para: Carl Mehner > CC: Ion Larranaga Azcue ; tls@ietf.org > Asunto: Re: [TLS] Breaking into TLS to protect customers >

Re: [TLS] Breaking into TLS to protect customers

Good point Yoav. And this positive side effect holds true in the health care and insurance industries as well, and is not an accident. It is one of the primary reasons this monitoring is performed. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Thursday, March 15, 2018

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

(We have many related discussions currently.. this seemed like the most appropriate thread for my response) Enterprises are asking for out-of-band TLS decryption, per use-cases outlined in draft-fenter-tls-decryption-00 (and others before that). The current proposal for said out-of-band TLS

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

Well, exactly. It seems like the following have equivalent security properties: - Shipping out each session's keys as lines in SSLKEYLOGFILE over an ECDHE TLS connection - Shipping out each session's keys as an ECIES-encrypted package carried in a TLS extension Either way, you're doing a DH

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

Yeah, as log as we know who we’re shipping it to and the user intends for us to send it to this entity. For the debugging case that we were talking about in Prague, sending the keys out-of-band should work fine. For some middlebox that needs to decrypt the traffic online, it needs the keys

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

Unless I'm wrong, with the visibility draft the client side is also unable to identify who the key material is being transferred to. Only the server-side can know it, so I think it's a similar case. Imagine a malicious user is able to subvert the communication between the server and the

Re: [TLS] TLS@IETF101 Agenda Posted

My responses for today are all in this message, including a response to Ralph. I'm going to try not to engage on this again until tomorrow. On Mar 14, 2018, at 6:52 PM, nalini elkins wrote: > 1. Multiple standards are likely to diverge. We don't need multiple

Re: [TLS] Breaking into TLS to protect customers

If I am conflating them, it’s on purpose to draw out the differences. I’m not an Equifax customer, for example. The key point in my note is this: how would TLS interception prevent these kinds of things, given that interceptable TLS did not? From: Yoav Nir Date:

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

On Thursday, 15 March 2018 05:51:31 CET Yoav Nir wrote: > 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

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

I have placed this poster in the moderator queue based on RFC2418: Participation is by individual technical contributors, rather than by formal representatives of organizations [0]. They can rejoin using a personal account or identify who they are in their email’s signature. spt [0]

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

On Wednesday, 14 March 2018 21:13:29 CET Benjamin Kaduk wrote: > 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.

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

Re: [TLS] Breaking into TLS to protect customers

I fail to see how the current draft can be used to provide visibility to an IPS system in order to detect bots that are inside the bank… On the one hand, the bot would never opt-in for visibility if it’s trying to exfiltrate data, so this capability would never get activated. And even if the

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. Artyom, yes, as far as I am concerned at least, please start a new thread. Sorry I am getting behind on responding to all the

Re: [TLS] Breaking into TLS to protect customers

On Thu, Mar 15, 2018 at 4:53 AM, Ion Larranaga Azcue wrote: > I fail to see how the current draft can be used to provide visibility to an > IPS system in order to detect bots that are inside the bank… > > In an effort to help clear up the use case and not weighing in on the

Re: [TLS] TLS@IETF101 Agenda Posted

[top-posted because the bulk of the quoted material really is necessary for context] Hi Nalini, It seems to me your and Stephen's recollections of events have two essential points in common (well, in my view they do) that I'd like to highlight here: 1. A number of your consortium's parties