Re: [TLS] TLS@IETF101 Agenda Posted

[Andrei Popov]

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
Sent: Thursday, March 15, 2018 10:29 AM
To: IETF TLS 
Subject: 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.

In fact, my mistake that was caught by Martin is exactly the reason that we 
want the experts in the TLS WG to review the document.

Russ

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

Re: [TLS] Breaking into TLS to protect customers

[Kathleen Moriarty]

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) actors
>> that are moving around the internal network leveraging existing access
>> rights of compromised accounts and privilege escalation
>> vulnerabilities.  These might be detectable with 'visibility'.
>> Patterns and behavior might be used to detect the APT use case whether
>> or not encryption protects the stream, but it is more difficult.
>
> Yes, they might, however, the best place for malware detection is on the
> edge (which is out of scope for "in the Datacenter" type connections) and
> the endpoint, where an agent is able to run that does not need to 'break in'
> to the TLS session. Yes, the Fenter draft talks about how malware endpoints
> can be anywhere in the network, and that they can delete logs as a reason to
> require out of band network decryption. However, if "breaking TLS" becomes
> an effective malware mitigation means, more malware makers may move to using
> app-level encryption (as some already have). Therefore, the conclusion we
> can draw is that malware is not a reasonable reason requiring this enhanced
> "visibility".

The example I provided is not about malware, it was about lateral
movement by threat actors within a network.  The initial compromise
that led to access within the network may have been through malware or
some other vulnerability, but I do think monitoring on an internal
network (encrypted or not, through logs or on the wire) is the use
case for attack detection that is plausible with the proposed
approach.

Best regards,
Kathleen

>
>
> -carl



-- 

Best regards,
Kathleen

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

Re: [TLS] Breaking into TLS to protect customers

[Carl Mehner]

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 access
> rights of compromised accounts and privilege escalation
> vulnerabilities.  These might be detectable with 'visibility'.
> Patterns and behavior might be used to detect the APT use case whether
> or not encryption protects the stream, but it is more difficult.

Yes, they might, however, the best place for malware detection is on the
edge (which is out of scope for "in the Datacenter" type connections) and
the endpoint, where an agent is able to run that does not need to 'break
in' to the TLS session. Yes, the Fenter draft talks about how malware
endpoints can be anywhere in the network, and that they can delete logs as
a reason to require out of band network decryption. However, if "breaking
TLS" becomes an effective malware mitigation means, more malware makers may
move to using app-level encryption (as some already have). Therefore, the
conclusion we can draw is that malware is not a reasonable reason requiring
this enhanced "visibility".


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

Re: [TLS] Breaking into TLS to protect customers

[Roland Zink]

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 persistent threat (APT) actors
> that are moving around the internal network leveraging existing access
> rights of compromised accounts and privilege escalation
> vulnerabilities.  These might be detectable with 'visibility'.
> Patterns and behavior might be used to detect the APT use case whether
> or not encryption protects the stream, but it is more difficult.

Yes, they might, however, the best place for malware detection is on 
the edge (which is out of scope for "in the Datacenter" type 
connections) and the endpoint, where an agent is able to run that does 
not need to 'break in' to the TLS session. Yes, the Fenter draft talks 
about how malware endpoints can be anywhere in the network, and that 
they can delete logs as a reason to require out of band network 
decryption. However, if "breaking TLS" becomes an effective malware 
mitigation means, more malware makers may move to using app-level 
encryption (as some already have). Therefore, the conclusion we can 
draw is that malware is not a reasonable reason requiring this 
enhanced "visibility".


I don't think you can make this conclusion when the fact that app-level 
encryption is used can be detected and blocked. However there might be 
ways to hide like steganography.




-carl


___
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] Breaking into TLS to protect customers

[Yoav Nir]

> 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 trying to 
> exfiltrate data…

The presumption is that any legitimate application would opt-in, so the IPS 
blocks any TLS connection that does not opt in.




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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stephen Farrell]

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 that was caught by Martin is exactly the reason
> that we want the experts in the TLS WG to review the document.

Two things:-

1. I disagree with your assertion. Broad review to improve
security is well worthwhile and is a reason to bring work
to the IETF. Figuring out the how to controversially yet
diligently make TLS (or any IETF protocol) *weaker* is not
part of our process, and would IMO be extremely long-term
damaging to the argument that IETF security review is a
benefit of work being done via the IETF's processes.

2. Having had that fairly fundamental error pointed out,
and given the serious amount of analysis done for TLS1.3,
and *not done* for this MitM enabler, (e.g. the >1 snooper
issue has some showstoppers IMO no matter how any MitM
capability proposal tries to tackle or avoid it) - would you
not now agree that your draft is far too far from baked to
be worth the WG's f2f time in London, even if the WG had
consensus to consider the topic, which I think we've all
acknowledged is not the case? (*)

Thanks,
S.

(*) I considered not making this point - it could suit my
arguments better if the WG have a sequence of drafts like
this and draft-green to dismiss I guess but in fairness
and just in case you're now happy to withdraw your request
for a slot, I figured it worth asking, as I continue to
think that the way this topic is being mishandled is a bad
plan for all concerned.

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


0x7B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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

[Salz, Rich]

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

[Yoav Nir]

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 products come with their 
own OpenSSL package.

TBH I don’t think an RFC would have that effect. Not every RFC gets implemented.


> On 15 Mar 2018, at 13:38, Hubert Kario  wrote:
> 
> 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 free.
>> 
>> None of these libraries support any of this functionality.
> 
> huh? Sure, it is not nicely packaged in to allow integration with 3rd party
> systems, and sometimes disabled by default, but it's hardly missing...
> 
> https://github.com/openssl/openssl/pull/1646 
> 
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format 
> 
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=393477 
> 
> 
>>> On 15 Mar 2018, at 2:16, Watson Ladd  wrote:
>>> 
>>> 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
>>> 
>>> ___
>>> 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 
>> 
> 
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com 
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic



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

Re: [TLS] Breaking into TLS to protect customers

[Ion Larranaga Azcue]

> -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
> 
> The example I provided is not about malware, it was about lateral movement
> by threat actors within a network.  The initial compromise that led to access
> within the network may have been through malware or some other
> vulnerability, but I do think monitoring on an internal network (encrypted or
> not, through logs or on the wire) is the use case for attack detection that is
> plausible with the proposed approach.

Ok, now it's clear for me. I don't know why I thought I had seen a couple of 
times these last days people talking about the need of IPS to decrypt traffic 
going from the enterprise to internet, trying to detect exfiltration of data or 
connections to a malware C, which is not the scope of the draft, and I 
thought we were starting to veer off-course in the discussion.

As usually happens, I've been looking for those previous messages (not too hard 
I must admit) and I have been unable to find them, so I probably misunderstood 
what someone meant...

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

Re: [TLS] Breaking into TLS to protect customers

[Ackermann, Michael]

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 12:58 AM
To: Rich Salz 
Cc: tls@ietf.org
Subject: 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 of the bank are protected, it’s a happy side effect 
(collateral benefit?). The object is to protect the system integrity and the 
data.

Yoav


On 15 Mar 2018, at 5:29, Salz, Rich > 
wrote:

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
· retailer Target, presumably subject to PCI-DSS rules
· Anthem health insurance, presumably a regulated industry
· Equifax, a financial-business organization (but apparently not 
regulated)
· Yahoo, a company created on and by and for the Internet (one would 
think they know better)
We could, of course, go on and on and on.

NONE of those organizations are using TLS 1.3.

So what kind of “protect the customer” requires breaking TLS?  And what 
benefits and increased protection will customers see?


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



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

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

[R du Toit]

(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 decryption is 
draft-rhrd-tls-tls13-visibility-01, which requires opt-in from the TLS server 
by way of a new “TLS Visibility” extension. If draft-fenter has all the 
requirements and draft-rhd is supposed to be the solution then the implication 
is that every TLS endpoint in the enterprise datacenter (and possibly outside 
the datacenter if those TLS endpoints do not enter via some TLS termination 
node) must support the proposed TLS extension.  I am also assuming that some 
enterprise key management solution product is already deployed in the 
datacenter, and that those products remotely manage the full lifecycle of the 
TLS endpoint RSA keys and certificates.  Summary: all endpoints must change, 
and all endpoints are managed.

 

So, why are we not discussing dynamic out-of-band TLS session secret sharing or 
TLS secret escrow as solutions? (I call it secrets instead of keys because TLS 
1.3 gives us the ability to share different parts of the session secret 
hierarchy, e.g. sharing “client/server_application_traffic_secret0” instead of 
sharing “Master Secret”).  The secrets would be shared by the actual TLS 
endpoints, so it requires no changes to TLS.  I do understand that it would 
introduce new connectivity requirements for datacenter TLS nodes, but that is 
why I have the paragraph above where I list my assumptions: those nodes would 
have to change anyway and those nodes are remotely managed..

 

--Roelof

 

From: TLS  on behalf of Hubert Kario 
Date: Thursday, March 15, 2018 at 7:38 AM
To: 
Subject: 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 free.

None of these libraries support any of this functionality.

 

huh? Sure, it is not nicely packaged in to allow integration with 3rd party 

systems, and sometimes disabled by default, but it's hardly missing...

 

https://github.com/openssl/openssl/pull/1646

 

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

 

https://bugs.chromium.org/p/chromium/issues/detail?id=393477

 

> On 15 Mar 2018, at 2:16, Watson Ladd  wrote:

> 

> 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

> 

> ___

> 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

 

 

-- 

Regards,

Hubert Kario

Senior Quality Engineer, QE BaseOS Security team

Web: www.cz.redhat.com

Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech 
Republic___

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] TLS interception technologies that can be used with TLS 1.3

[Richard Barnes]

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 with the key recipient's public key and using
that to encrypt the keys.

On Thu, Mar 15, 2018 at 6:42 PM, Salz, Rich  wrote:

> I think if we ship the keys over some kind of secure socket layer we
> should be okay, right?
>
>
>
>
>
> *From: *Yoav Nir 
> *Date: *Thursday, March 15, 2018 at 6:41 PM
> *To: *Richard Barnes 
> *Cc: *Rich Salz , Hubert Kario , "
> tls@ietf.org" 
> *Subject: *Re: [TLS] TLS interception technologies that can be used with
> TLS 1.3
>
>
>
> IIUC not quite. There is an API, so the application that uses the library
> can get the keys. The application can then save it to a file, send it to a
> central repository, send it to the government, or whatever else it might
> want to do.
>
>
>
> There is no built-in setting where OpenSSL writes the keys to a file, nor
> do applications such as web servers do this AFAIK.
>
>
>
> It should not be difficult to write, but is not provided in off-the-shelf
> software.
>
>
>
> Making the library send this in-band in some protocol extension is a far
> bigger endeavor. It’s also a dangerous switch to leave lying around.
>
>
>
> On 16 Mar 2018, at 0:16, Richard Barnes  wrote:
>
>
>
> Just to confirm that I understand the scope of the discussion here:
>
>
>
> - TLS libraries have facilities to export keys from the library
>
> - Obviously, it's possible to ship these exported keys elsewhere (`tail -f
> $SSLKEYLOGFILE | nc $LOGBOX`)
>
>
>
> So all we're really talking about is whether to define a way to do the
> shipment of the exported keys in-band to the TLS session.
>
>
>
>
>
> On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich  wrote:
>
> 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
>
>
>
>
>
___
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

[Yoav Nir]

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 
before the first data record goes out. I don’t see how we can do that without 
interleaving it with the handshake.



> On 16 Mar 2018, at 0:42, Salz, Rich  wrote:
> 
> I think if we ship the keys over some kind of secure socket layer we should 
> be okay, right?
> 
> 
> From: Yoav Nir 
> Date: Thursday, March 15, 2018 at 6:41 PM
> To: Richard Barnes 
> Cc: Rich Salz , Hubert Kario , 
> "tls@ietf.org" 
> Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3
> 
> IIUC not quite. There is an API, so the application that uses the library can 
> get the keys. The application can then save it to a file, send it to a 
> central repository, send it to the government, or whatever else it might want 
> to do. <>
> 
> There is no built-in setting where OpenSSL writes the keys to a file, nor do 
> applications such as web servers do this AFAIK.
> 
> It should not be difficult to write, but is not provided in off-the-shelf 
> software.
> 
> Making the library send this in-band in some protocol extension is a far 
> bigger endeavor. It’s also a dangerous switch to leave lying around.
> 
> 
>> On 16 Mar 2018, at 0:16, Richard Barnes > 
>> wrote:
>> 
>> Just to confirm that I understand the scope of the discussion here:
>> 
>> - TLS libraries have facilities to export keys from the library
>> - Obviously, it's possible to ship these exported keys elsewhere (`tail -f 
>> $SSLKEYLOGFILE | nc $LOGBOX`)
>> 
>> So all we're really talking about is whether to define a way to do the 
>> shipment of the exported keys in-band to the TLS session.
>> 
>> 
>> On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich > > wrote:
>>> 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 
>>> 


signature.asc
Description: Message signed with OpenPGP
___
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

[Ion Larranaga Azcue]

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 middlebox. If this user manages to convince the server that it 
should use its own keys instead of the ones the middlebox owns, the attacker is 
able to happily decrypt all traffic by using a mechanism we have provided him 
with, and nobody would realize it (because the client has no way to know who 
the key material is being shared with)

And yes, if the key material is shared out-of-band we have a similar problem, I 
don't deny it. I think that this comes down to a philosophycal dylemma.. We 
have two different mechanisms that amount to a similar security level:

- key material is shared out-of-band using some additional mechanism, defined 
outside of TLS
- key material is shared in-band using the TLS extension

Both mechanisms seem to provide, in theory, similar security levels. The 
difference is that if TLS extensions handle it, it's TLS the responsible for 
the security downgrade, whereas in the other case... well, we can't prevent 
anyone from doing what they want with their key material so...

I would vote for out-of-band sharing if enterprises need it, delegating this in 
a completely different protocol. TLS should be as clean and as secure as 
possible.


De: TLS  en nombre de Yoav Nir 
Enviado: jueves, 15 de marzo de 2018 23:49
Para: Rich Salz
Cc: tls@ietf.org
Asunto: 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 
before the first data record goes out. I don't see how we can do that without 
interleaving it with the handshake.



On 16 Mar 2018, at 0:42, Salz, Rich > 
wrote:

I think if we ship the keys over some kind of secure socket layer we should be 
okay, right?


From: Yoav Nir >
Date: Thursday, March 15, 2018 at 6:41 PM
To: Richard Barnes >
Cc: Rich Salz >, Hubert Kario 
>, 
"tls@ietf.org" >
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3

IIUC not quite. There is an API, so the application that uses the library can 
get the keys. The application can then save it to a file, send it to a central 
repository, send it to the government, or whatever else it might want to do.

There is no built-in setting where OpenSSL writes the keys to a file, nor do 
applications such as web servers do this AFAIK.

It should not be difficult to write, but is not provided in off-the-shelf 
software.

Making the library send this in-band in some protocol extension is a far bigger 
endeavor. It's also a dangerous switch to leave lying around.


On 16 Mar 2018, at 0:16, Richard Barnes > wrote:

Just to confirm that I understand the scope of the discussion here:

- TLS libraries have facilities to export keys from the library
- Obviously, it's possible to ship these exported keys elsewhere (`tail -f 
$SSLKEYLOGFILE | nc $LOGBOX`)

So all we're really talking about is whether to define a way to do the shipment 
of the exported keys in-band to the TLS session.


On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich 
> wrote:
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

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Ted Lemon]

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 standards, so this isn't an issue.   What you need is to 
define the behavior that you need from your TLS implementation to give you the 
visibility that you want.

> 2.  The TLS WG of the IETF has many of the world's experts in defining such 
> protocols.  The years of collective expertise is remarkable.   We want to 
> work with the TLS group not try to recreate it.

Of course, it would be ideal for you if you could get the TLS working group to 
do this work for you.

> 3.   The reason I support the enterprises and their voice in TLS is because I 
> am naive enough to actually believe in the IETF.  I believe that technical 
> truth matters.  That it is not actually the Vendor Engineering Task Force.  
> That is a group of the vendors, by the vendors and for the vendors.   I could 
> see when this whole thing with taking away RSA was happening that correct 
> though it may be, it was going to cause enormous disruption for many, many 
> people in the commercial world.  You may not believe it, but I am actually 
> doing this because I really believe that we need one set of standards that 
> everyone can use.  I want it to be in the TLS WG.  I want the TLS WG to be 
> credible and succeed and I want the IETF to succeed.  I believe that the 
> Internet needs it.

The problem isn't that we don't believe that it will involve significant work 
for you to secure your customer's data.

> 4.  Again, believe it or not, the TLS WG needs the enterprises.  Of course, 
> this is all my opinion only.   These enterprises are a huge group of users of 
> the IETF protocols and TLS in particular.   The feedback of users is 
> irreplaceable.  Who are we building the protocols for if not the users?  
> Sure, there are multiple sets, but these are a very large group.  

This is the crux of the question: who are the users whose needs the TLS working 
group is serving?   Any discussion that doesn't begin by answering this 
question is going to be non-terminal.   I believe it's your position that the 
"user" is the large corporation; an alternate view, which appears to be shared 
by quite a few participants here, is that the user is the end user: the person 
who, if their data security is compromised, will wind up bearing the cost of 
that compromise.

> 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 how you can 
> say what you are saying.

None of these applications require changes to TLS 1.3.   If you think they do, 
you need to walk us through your reasoning.  The reason we can say what we are 
saying is that we understand that none of what you have mentioned here requires 
that TLS 1.3 be weakened.

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

That's a great analogy, but we are talking about software, not houses.   There 
is no technical reason why switching to TLS 1.3 requires you to build a new 
house.   It does require you to update your software, and there is no doubt a 
real cost to that.  There may even be software that you will have to stop 
using.  But any software that you would have to stop using is software you 
already should not be using, because it's not supported.

> I would not agree with that.  People understand that sometimes they have to 
> pay when there are protocol and other changes.  It is a question of if you 
> could do everything that you needed to do to protect your customers even if 
> you re-built your network from the ground up.

I don't think there's any question that if you rebuilt your network from the 
ground up, you could use TLS 1.3.   If you think this is not the case, it would 
help if you could say what precisely stands in the way.

On Mar 14, 2018, at 10:32 PM, Ralph Droms  wrote:
> And there is a name for this sort of labeling - it's called an "ad hominem 
> attack".  I don't believe anyone is employing "consensus by exhaustion".  
> Please don't attach unwarranted labels to honest attempts to explain 
> requirements and develop solutions.

Ralph, the problem is not that these attempts to explain requirements are not 
honest.  It is that until we agree on who we are protecting, talking about 
requirements doesn't really help: the requirements of people who are not our 
priority are interesting, but not important.

And because we are discussing requirements before we 

Re: [TLS] Breaking into TLS to protect customers

[Salz, Rich]

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: Thursday, March 15, 2018 at 12:57 AM
To: Rich Salz 
Cc: "tls@ietf.org" 
Subject: 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 of the bank are protected, it’s a happy side effect 
(collateral benefit?). The object is to protect the system integrity and the 
data.

Yoav


On 15 Mar 2018, at 5:29, Salz, Rich > 
wrote:

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
· retailer Target, presumably subject to PCI-DSS rules
· Anthem health insurance, presumably a regulated industry
· Equifax, a financial-business organization (but apparently not 
regulated)
· Yahoo, a company created on and by and for the Internet (one would 
think they know better)
We could, of course, go on and on and on.

NONE of those organizations are using TLS 1.3.

So what kind of “protect the customer” requires breaking TLS?  And what 
benefits and increased protection will customers see?


___
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] TLS interception technologies that can be used with TLS 1.3

[Hubert Kario]

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 free.
> 
> None of these libraries support any of this functionality.

huh? Sure, it is not nicely packaged in to allow integration with 3rd party 
systems, and sometimes disabled by default, but it's hardly missing...

https://github.com/openssl/openssl/pull/1646

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format

https://bugs.chromium.org/p/chromium/issues/detail?id=393477

> > On 15 Mar 2018, at 2:16, Watson Ladd  wrote:
> > 
> > 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
> > 
> > ___
> > 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


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

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] https://tools.ietf.org/rfcmarkup?doc=2418#section-1


> Begin forwarded message:
> 
> From: Hot Middlebox 
> Subject: Re: [TLS] Four concerns (was Re: draft-rhrd-tls-tls13-visibility at 
> IETF101)
> Date: March 14, 2018 at 22:08:44 GMT
> To: "Salz, Rich" 
> Cc: IETF TLS 
> 
> 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 experience 
> how a browser plug-in client (to be provided) can be used in conjunction with 
> a fine grained Middlebox Security Protocol for Middlebox discovery and 
> controlled visibility by an end-user in a way that meets both user and 
> regulatory interests.  The draft specification will be published in two weeks.
> 
> --the Hot Middlebox organizers
> 
> On Wed, 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 point.  I assume the authors did not realize 
> this. That shows how hard, and risky, it is to get this right.  In the US, we 
> have been having arguments where the national police force (FBI) is insisting 
> that tech companies can create a "golden key" that only they can use, and the 
> security people are saying it is impossible.  This seems like another 
> instance, no?
> 
> Oh heck, let me ask the uncomfortable question:  Russ, did you know this or 
> was Martin's point new to you?
> 
> /r$
> 
> 
> ___
> 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] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration

[Hubert Kario]

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.  If we allowed at most one external
> > > PSK in a given ClientHello, then aborting the handshake on binder
> > > failure would be the correct choice, as discovering a valid identity
> > > would require discovering a valid key/password as well.
> > 
> > but identity/binder may be invalid only because the server was restarted
> > and generated a new in-memory key; we don't want to abort connection in
> > such
> For an external PSK?  That hardly sounds like "external" to me...

not my fault that what we called just "PSK"s in TLS 1.2 is now "external PSKs" 
in TLS 1.3... I wanted to be unambiguous, so please, can we discuss the issue, 
not semiotics?

> > situation, continuing to a regular handshake is necessary then for good
> > user experience (and likely, even security, given the history of TLS
> > version fallbacks)
> > 
> > > Disallowing multiple external PSKs would make migration scenarios a
> > > little more annoying, but perhaps not fatally so.
> > 
> > not only migration, but session resumption and regular PSK at the same
> > time
> > too - for session resumption you may not do DH, while for initial
> > handshake
> > with PSK you may want to to gain PFS...
> > 
> > so as tempting as the removal of multiple PSKs from ClientHello is, I'm
> > afraid the fallout is far too large to do it
> 
> I did not say removal of multiple PSKs, rather removal of multiple
> *external* PSKs.

we do not have a reliable mechanism of differentiating between external and 
resumption PSKs while parsing Client Hello

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS@IETF101 Agenda Posted

[nalini elkins]

 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 me
>ahead of time who, from what "enterprises," would be
>in the room looking for what. As an AD I was always
>happy to meet folks and have quiet discussions about
>how to engage with the IETF or explore some detail of
>how to get something done, I definitely did draw a
>line well before private meetings aiming to overthrow
>established WG consensus.

>While that all might be put down to a tactical error
>in which advice to follow with whom when initially
>engaging with the IETF, from my POV it was the epitome
>of a request for a smokey-back room discussion.

>So yes, I do find that there are questions here about
>smokey back rooms indeed.

1.  With respect, I contend that you are conflating what happened then with
what I am suggesting now.

2.  Also, your description of what happened then does not match with my
memory.  We may
have an honest disagreement or recollection of events.  I believe I have
the original
email chain somewhere & can try to find it, if necessary.

My version of the events is:

1.  A couple of years ago, I was involved with some "enterprises" who felt
they had an
issue with the upcoming TLS1.3 standard.  In particular, the deprecation of
RSA.


2.   They were concerned about the reputational risk to their company of
speaking
in a public forum.   (This is a huge issue for many companies.)  Also, they
were not used to writing Internet Drafts or presenting at an IETF group.


3.  I had no experience with such a situation so I was not sure what to do
either.
My own work is in IPPM (if anyone is interested, you can look at my work
in RFC8250), so I was not involved with the TLS group very much either.
(A situation which has since been corrected.  I now am happy to know
many of you quite well.) (Still no claims to being a crypto expert, though!)

I asked a former Chair of the IETF for advice.  He suggested asking for a
session with the leadership of the TLS group under Chatham House rules.

I did so.

As I recall, I asked to have a discussion of the issues to see what we
should do.
I never asked for any consensus of the WG to be overturned.  I may be a dim
bulb but I am not a complete idiot.   I do have some idea of how things
work as
far as WG consensus.

Again, as I recall, you replied at some length about "subverting the
process".
After a few more somewhat emotional emails back and forth, where I was not
able to convey
my point adequately or to reach an understanding, I gave up on that route.

It is completely possible that I did not ask correctly or convey the right
information.
It was a new situation to me & as I say, I was not sure what to do.  I did
my best.

If needed, I can look for the original email chain.


4.  Then, I went back to these "enterprises".  They had to go all the way
to the
CEO of their company to get authority to speak publicly.   They did so at
the Chicago IETF.

And, you know what, I am going to do everything I can to help these guys.
They have a point of view that deserves to be represented.  They have
put in a huge amount of time and effort to try to present what they feel
will be a real problem for their company.  They are not doing it for any
other reason.

Again, they are not used to writing Internet drafts.  And, I am not as much
as help as I could be to them in writing drafts for TLS as that is not
where
I live, so to speak.  If this was an issue in performance metrics, I could
write the drafts for them.  But, this is TLS, so we have to get others to
help.
We have tried as much as we can to follow the process.   We are all
imperfect, we are doing our best.


5.  This issue with people being able to speak publicly is real.  It needs
to
be recognized.  Not everyone works for an academic institution or
companies which support speaking openly about network architecture
issues.

Even some of the network product vendors who are starting to speak
openly on this issue have had to talk to their CEOs before commenting.
Not everyone will go to such lengths.  They will mostly just give up.
Which is unfortunate for everyone.  Including the IETF.

I completely understand why deliberations of something as important
as TLS need to be public and in the open.  I support that.  I am just
saying that there is an important constituency for whom speaking in
an open forum is a real issue.  Frankly, this is why we formed the
"consortium".

Nalini

On Wed, Mar 14, 2018 at 5:13 PM, Stephen Farrell 
wrote:

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

Re: [TLS] Breaking into TLS to protect customers

[Ion Larranaga Azcue]

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 
bot was nice enough as to opt-in for visibility, the party responsible for 
providing the IPS with the required information is the server, which in this 
case is under control of the attacker. There is no way the attacker’s server 
will negotiate with the IPS the required keys to decrypt the channel (most 
likely it can’t even communicate with it).

And if you decide to close that connection because of the lack of visibility, 
well… 99% of TLS servers in internet will not negotiate visibility keys with 
your specific IPS, so you could as well close all TLS traffic going outside. 
And you don’t need visibility for this, only a well-configured firewall.

So, maybe I’m wrong, but I think that this specific use case (analysis of 
either malicious or legitimate clients’ traffic going from the enterprise 
network to outside servers) is not covered by the draft under discussion 
because the remote server will never negotiate the encryption keys with the 
IPS. For me, the only way to provide visibility within this case is by actively 
proxying every connection, something that proponents of the need for visibility 
don’t seem to be comfortable with, and which in my opinion does not require 
lowering the TLS protocol security level.

Or maybe I misunderstood the use case altogether…


De: TLS [mailto:tls-boun...@ietf.org] En nombre de Yoav Nir
Enviado el: jueves, 15 de marzo de 2018 5:58
Para: Rich Salz 
CC: tls@ietf.org
Asunto: 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 of the bank are protected, it’s a happy side effect 
(collateral benefit?). The object is to protect the system integrity and the 
data.

Yoav


On 15 Mar 2018, at 5:29, Salz, Rich > 
wrote:

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
· retailer Target, presumably subject to PCI-DSS rules
· Anthem health insurance, presumably a regulated industry
· Equifax, a financial-business organization (but apparently not 
regulated)
· Yahoo, a company created on and by and for the Internet (one would 
think they know better)
We could, of course, go on and on and on.

NONE of those organizations are using TLS 1.3.

So what kind of “protect the customer” requires breaking TLS?  And what 
benefits and increased protection will customers see?


___
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] Breaking into TLS to protect customers

[nalini elkins]

 > 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 emails.   But, I am very
interested in what you have to say.  I just can't keep up.   Will do my
best to respond as promptly as possible but there are many of you and not
so many of me.

Nalini

On Thu, Mar 15, 2018 at 3:33 AM, Artyom Gavrichenkov 
wrote:

> 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
>> 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
>>
>>- retailer Target, presumably subject to PCI-DSS rules
>>- Anthem health insurance, presumably a regulated industry
>>- Equifax, a financial-business organization (but apparently not
>>regulated)
>>- Yahoo, a company created on and by and for the Internet (one would
>>think they know better)
>>
>> We could, of course, go on and on and on.
>>
>>
>>
>> NONE of those organizations are using TLS 1.3.
>>
>>
>>
>> So what kind of “protect the customer” requires breaking TLS?  And what
>> benefits and increased protection will customers see?
>>
>>
>>
>>
>> ___
>> 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
>
>


-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Breaking into TLS to protect customers

[Kathleen Moriarty]

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

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 access
rights of compromised accounts and privilege escalation
vulnerabilities.  These might be detectable with 'visibility'.
Patterns and behavior might be used to detect the APT use case whether
or not encryption protects the stream, but it is more difficult.

If an attacker was using their own server and the fingerprints were
different, detection with encryption would be possible even if it is
more difficult. Threat sharing groups do exchange detection techniques
that involve encrypted traffic for the latter case.  And I think
everyone agrees, that this is not a use case the proponents are trying
to cover.

Best,
Kathleen

>
> 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 bot was nice enough as to opt-in for visibility, the party responsible
> for providing the IPS with the required information is the server, which in
> this case is under control of the attacker. There is no way the attacker’s
> server will negotiate with the IPS the required keys to decrypt the channel
> (most likely it can’t even communicate with it).
>
>
>
> And if you decide to close that connection because of the lack of
> visibility, well… 99% of TLS servers in internet will not negotiate
> visibility keys with your specific IPS, so you could as well close all TLS
> traffic going outside. And you don’t need visibility for this, only a
> well-configured firewall.
>
>
>
> So, maybe I’m wrong, but I think that this specific use case (analysis of
> either malicious or legitimate clients’ traffic going from the enterprise
> network to outside servers) is not covered by the draft under discussion
> because the remote server will never negotiate the encryption keys with the
> IPS. For me, the only way to provide visibility within this case is by
> actively proxying every connection, something that proponents of the need
> for visibility don’t seem to be comfortable with, and which in my opinion
> does not require lowering the TLS protocol security level.
>
>
>
> Or maybe I misunderstood the use case altogether…
>
>
>
>
>
> De: TLS [mailto:tls-boun...@ietf.org] En nombre de Yoav Nir
> Enviado el: jueves, 15 de marzo de 2018 5:58
> Para: Rich Salz 
> CC: tls@ietf.org
> Asunto: 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 of the bank are protected, it’s a happy side effect
> (collateral benefit?). The object is to protect the system integrity and the
> data.
>
>
>
> Yoav
>
>
>
> On 15 Mar 2018, at 5:29, Salz, Rich  wrote:
>
>
>
> 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
>
> · retailer Target, presumably subject to PCI-DSS rules
>
> · Anthem health insurance, presumably a regulated industry
>
> · Equifax, a financial-business organization (but apparently not
> regulated)
>
> · Yahoo, a company created on and by and for the Internet (one would
> think they know better)
>
> We could, of course, go on and on and on.
>
>
>
> NONE of those organizations are using TLS 1.3.
>
>
>
> So what kind of “protect the customer” requires breaking TLS?  And what
> benefits and increased protection will customers see?
>
>
>
>
>
> ___
> 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
>



-- 

Best regards,
Kathleen

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

Re: [TLS] TLS@IETF101 Agenda Posted

[Stan Kalisch]

[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 are, at minimum, reticent to come, or 
are restricted from coming, forward in this large public IETF forum.

2.  Your consortium is trying to prove a negative:  that some fundamental 
feature doesn't exist in the TLS 1.3 draft.  I say "some fundamental feature" 
because I'm not sure those for or opposed can say exactly what that technical 
feature is.  We know it allows the inspection of data, and we know there are 
theories on how that would securely work.

Here, I think, is a substantial part of the problem:  your consortium isn't 
pushing a specific technical feature, and the WG doesn't know specifically who 
they are.  I think this speaks to much of the difficulty the WG has in engaging 
with you regarding the TLS 1.3 and so-called "visibility" drafts.


Thanks,
Stan

> On Mar 15, 2018, at 4:47 AM, nalini elkins  wrote:
> 
> 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 me
> >ahead of time who, from what "enterprises," would be
> >in the room looking for what. As an AD I was always
> >happy to meet folks and have quiet discussions about
> >how to engage with the IETF or explore some detail of
> >how to get something done, I definitely did draw a
> >line well before private meetings aiming to overthrow
> >established WG consensus.
> 
> >While that all might be put down to a tactical error
> >in which advice to follow with whom when initially
> >engaging with the IETF, from my POV it was the epitome
> >of a request for a smokey-back room discussion.
> 
> >So yes, I do find that there are questions here about
> >smokey back rooms indeed. 
> 
> 1.  With respect, I contend that you are conflating what happened then with 
> what I am suggesting now.
> 
> 2.  Also, your description of what happened then does not match with my 
> memory.  We may
> have an honest disagreement or recollection of events.  I believe I have the 
> original
> email chain somewhere & can try to find it, if necessary.
> 
> My version of the events is:
> 
> 1.  A couple of years ago, I was involved with some "enterprises" who felt 
> they had an 
> issue with the upcoming TLS1.3 standard.  In particular, the deprecation of 
> RSA.   
> 
> 
> 2.   They were concerned about the reputational risk to their company of 
> speaking
> in a public forum.   (This is a huge issue for many companies.)  Also, they
> were not used to writing Internet Drafts or presenting at an IETF group.
> 
> 
> 3.  I had no experience with such a situation so I was not sure what to do 
> either.
> My own work is in IPPM (if anyone is interested, you can look at my work 
> in RFC8250), so I was not involved with the TLS group very much either. 
> (A situation which has since been corrected.  I now am happy to know 
> many of you quite well.) (Still no claims to being a crypto expert, though!)
> 
> I asked a former Chair of the IETF for advice.  He suggested asking for a 
> session with the leadership of the TLS group under Chatham House rules.
> 
> I did so.
> 
> As I recall, I asked to have a discussion of the issues to see what we should 
> do.
> I never asked for any consensus of the WG to be overturned.  I may be a dim
> bulb but I am not a complete idiot.   I do have some idea of how things work 
> as
> far as WG consensus.
> 
> Again, as I recall, you replied at some length about "subverting the process".
> After a few more somewhat emotional emails back and forth, where I was not 
> able to convey 
> my point adequately or to reach an understanding, I gave up on that route.
> 
> It is completely possible that I did not ask correctly or convey the right 
> information.
> It was a new situation to me & as I say, I was not sure what to do.  I did my 
> best.
> 
> If needed, I can look for the original email chain.
> 
> 
> 4.  Then, I went back to these "enterprises".  They had to go all the way to 
> the
> CEO of their company to get authority to speak publicly.   They did so at 
> the Chicago IETF.
> 
> And, you know what, I am going to do everything I can to help these guys.
> They have a point of view that deserves to be represented.  They have 
> put in a huge amount of time and effort to try to present what they feel
> will be a real problem for their company.  They are not doing it for any
> other reason.
> 
> Again, they are not used to writing Internet drafts.  And, I am not as much
> as help as I could be to them in writing drafts for TLS as that is not where 
> I live, so