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
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
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
(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
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
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
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
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
> 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
> -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
>
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
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)
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
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
[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
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
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
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.
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]
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:
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
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
> 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
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
24 matches
Mail list logo