Re: [TLS] Comment on draft-sullivan-tls-opaque-00

[steve]

On 04/08/2021, 14:43, "Scott Fluhrer (sfluhrer)"  wrote:
> 
> I am glad that someone in the working group is looking at this.  However, as 
> I reviewed this before the wg meeting, I was completely puzzled by this text 
> (from section 6.1):
> 
> 3DH
> 
>C computes K = H(g^y ^ PrivU || PubU ^ x || PubS ^ PrivU || IdU || IdS )
>S computes K = H(g^x ^ PrivS || PubS ^ y || PubU ^ PrivS || IdU || IdS )
> 

There are three errors in this the two you pointed out and the third term. The 
correct K calculations for 3DH are:

C computes K = H(g^y ^ PrivU || PubS ^ x|| g^y ^ x || IdU || IdS)
S computes K = H(PubU ^ y|| g^x ^ PrivS || g^x ^ y || IdU || IdS)

Where C has x, g^y, PubS, PrivU and S has y, g^x, PubU, PrivS. Which are 
calculated like:
g^x = g ^ x(yes I know it's bad to name it like
g^y = g ^ y this, but that's how they did it)
PubS = g ^ PrivS
PubU = g ^ PrivU

Although the terms can be in any order and I don't speak for them, but those 
are the correct terms with matching counterparts.

> Obviously these needs to be the same for an honest client-server pair.  I 
> can't see where the above variables are defined in the doc; I would assume 
> that the meanings are:
> 
> 
>   *   x, y are the private values from the ephemeral DH operation, and are 
> randomly selected for each exchange.
>   *   PrivU, PubU, PrivS, PubS are static values from the Opaque record.
> 

That's how I read it.

> However, if that's the case, I can't see how that could work; for one, g^y ^ 
> PrivU and g^x ^ PrivS would be different values, and so differing values 
> would be stirred into the Master Secret.  In addition, I can't see how PubU ^ 
> x (where PubU and x would appear to be client specific) could be expected to 
> be the same as PubS ^ y (as both those values would be server specific).
> 
> What am I missing?
> 

Those are actual problems. As a side note 3DH looks like this where each 
straight line is a DH calculation (hopefully those two lines look like they 
make an "X"). i_* being their identity public-private key pairs (PrivU, PubU, 
PrivS, PubS) and e_* being their ephemeral public-private key pairs (x, g^x, y, 
g^y).

i_c   i_s
   \ /
 \ /
 / \
   / \
e_c - e_s

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Steve Fenter]

I'd like to echo Dale's sentiments on the error codes.  I've done a fair amount 
of TLS handshake troubleshooting, and it's usually long and painful because the 
error codes are so vague. Another factor in debugging is that people 
troubleshooting TLS in the enterprise are typically not the same level of 
experts as those who are writing TLS code.  The TLS working group folks seem to 
have their fingers in TLS every day and know it backwards and forwards, so 
debugging a problem is not so difficult for them. They can also read code to 
figure out what is going on. In contrast, I see a TLS handshake problem once 
every few months.  The rest of the time I'm looking at HTTP, SQL, SMB, or 
whatever. So enterprise troubleshooters are not going to be as deep in their 
understanding of TLS by the nature of their jobs, and they need all the help 
they can get (like from descriptive error messages).  The vague error messages 
are leading directly to more downtime, and this should be balanced with the 
other security needs. I'm not saying this needs to be fixed immediately, but it 
should be considered somewhere down the road.

> On Mar 6, 2018, at 9:35 PM, wor...@ariadne.com (Dale R. Worley) wrote:
> 
> Colm MacCárthaigh  writes:
>> On the specific suggestion of having more granular error codes, I think
>> this is a dangerous direction to take lightly; there's at least one
>> instance where granular TLS alert messages have directly led to security
>> issues by acting as oracles that aided the attacker.
>> 
>> There's a general conjecture that the more information that is provided to
>> attackers, the more easily they can leverage into a compromise. Personally
>> I believe that conjecture, and would actually prefer to see fewer signals,
>> ideally as few as one big error code. There is a trade-off against
>> debugability, but I've only seen a handful of people have the skills to
>> debug low level TLS issues and it doesn't seem worth the risk. Others
>> disagree, which is valid, but it's at least an area of reasonable
>> contention.
> 
> I believe I've heard that position stated before, and I give it
> credibility.  I retreat to the statement I made at the top of my review,
> that I'm not experienced in security.  OTOH, I've spent a lot of the
> previous couple of decades debugging SIP call flows, so I've learned to
> appreciate any aid to debuggability that exists.
> 
> I'm tempted to consider this a classic case of conflicting requirements,
> and ask if our cryptographic experience can help us square this circle.
> 
> Dale
> 
> ___
> 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 for enterprise "visibility" (don't do it)

[Steve Fenter]

MITM as a solution doesn't scale for the needs of the enterprise.  Packet 
decryption and inspection is needed at many locations within the data center: 
at many tiers of an application, within the virtual environment, and within the 
cloud environment, all of which may be TLS encrypted.  Speaking as a 
troubleshooter, a problem can happen anywhere in the enterprise network, and 
there are thousands of locations where I need to be able to take a packet trace 
and decrypt it in order to find a slow or failing transaction.

The biggest problem I see with the key escrow solutions being suggested is that 
decryption is in some cases taking place in real time, even though it's out of 
band. This is being done, for example, for security inspection, for fraud 
monitoring, and for application performance monitoring.  TLS decryption 
appliances are going to be getting packets off of 100 gig links, and when the 
packet arrives the keys have to be there.  At this speed there's not a lot of 
time for queuing packets and waiting for keys. If we are going to use exported 
ephemeral keys, I think placing them in the packet as in draft-rhrd is the only 
scalable way to accomplish this.

In response to unwillingness to change, enterprises are doing things today that 
work and that solve our business problems. The alternative suggestions being 
made, like MITM and endpoint monitoring, don't solve our business problems.

In response to how much time we have, it was recently stated on the list that 
NIST has published a draft that disallows all non-DH cipher suites, which 
includes TLS 1.2.  TLS 1.2 with Diffie-Hellman only will be just as big of a 
problem for enterprises as TLS 1.3 is.  I don't have a crystal ball, but I 
don't I think the RSA key exchange is going to last five years as has been 
suggested.  And whenever RSA is deprecated, it takes a long time to implement a 
new solution in a large enterprise, so we have to be well out in front of the 
problem,

Steve Fenter

> On Mar 24, 2018, at 3:31 PM, Tony Arcieri <basc...@gmail.com> wrote:
> 
>> On Fri, Mar 23, 2018 at 11:26 PM, Alex C <immi...@gmail.com> wrote:
>> As I understand it (poorly!) the idea is exactly to have a single system on 
>> the network that monitors all traffic in cleartext.
> 
> And more specifically: to be able to *passively* intercept traffic and allow 
> it to be decrypted by a central system. "Visibility" with an active MitM is a 
> solved problem: have the MitM appliance double as an on-the-fly CA and 
> install its root certificate in the trust stores of all the clients you 
> intend to MitM.
> 
>> It's fundamentally impossible to prevent someone from copying all their 
>> traffic to another system in cleartext. If they're going to do it, they will.
>> The functionality is exactly the same as what could be achieved by 
>> installing monitoring software on each endpoint, but the logistics are 
>> different since the monitoring is centralized.
> 
> The response from "visibility" proponents is "endpoint agents are hard". 
> However, it seems like there is a simple solution to this problem which 
> should be compatible with their existing monitoring architectures and require 
> no changes to TLS:
> 
> Instrument TLS servers and/or client libraries used by internal enterprise 
> applications with a little shim that extracts the session master secret, then 
> makes another TLS connection to a TLS session key escrow service, and goes 
> "here's the session master secret for a session between X.X.X.X and Y.Y.Y.Y 
> with nonce ...". It could even be encrypted-at-rest to a particular 
> public key in advance (which could correspond to e.g. an HSM-backed 
> decryption key).
> 
> Enterprises could continue to passively collect TLS sessions in whatever 
> manner they already do, and decrypt traffic at will, it would just require 
> looking up the session key for a particular session in a key escrow database 
> rather than having a single key-to-the-kingdom.
> 
> This approach requires no changes to TLS, no changes to how "visibility" 
> systems collect traffic, and should provide better security in that using 
> session master secrets better scope the authority conferred to the decryption 
> service than D-H keys which can grant authority to e.g. resume TLS sessions.
> 
> The downsides are you have to instrument clients and/or servers and have the 
> decryption service maintain a key escrow database.
> 
> However, "visibility" proponents seem unwilling to accept any changes to 
> anything they presently do today. This is coupled with a sort of artificial 
> emergency where they claim (or outright lie) that compliance with industry 
> standards will require them to ship TLS 1.3 everywhere tomorrow. Th

Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)

[Steve Fenter]

To clarify for anyone who has confusion on the enterprise TLS visibility use 
case, I think enterprises need to be able to do out-of-band decryption anywhere 
in the network that they own.  It would be reasonable to terminate TLS on the 
enterprise's Internet connection, both inbound TLS and outbound TLS, as well as 
on business to business connections.  We could run standard TLS 1.3 on these 
external connections, and then run our modified TLS on the inside.

We also have internal browsers as well as other internal clients going to 
internal TLS servers, and these need deep packet inspection as well.  
Terminating TLS on the internal WAN head-end 
is less attractive, because there are significant sites outside of the data 
center that need troubleshooting and network security monitoring.  For example, 
a large metropolitan area may have many office buildings with thousands of 
users as well as local servers.  There can also be thousands of branch-type 
offices.  We don't want to be blind to these large areas of our enterprise 
network.  I think "scoping the solution to the data center" is the wrong way to 
phrase this, but rather it should be scoping to the internal enterprise 
network, owned and operated by the enterprise.

Also, while there are some enterprises who terminate TLS coming in from the 
Internet and then run clear text on the inside, there are others who run new 
TLS sessions internally.  There is a need for packet decryption and inspection 
at many layers of this internal TLS network.

Steve Fenter

> On Mar 24, 2018, at 7:37 PM, Ion Larranaga Azcue <ila...@s21sec.com> wrote:
> 
> I recognize I may lack context, because I have only seen Steve Fenter's 
> slides, but apart from it not reaching consensus, the scenario it presents 
> (user connecting to online banking service) seems to be visibility of 
> connections from the internet to internal servers. 
> 
> I think that not even visibility proponents agree between them, as sometimes 
> they seem to require "server-to-server" visibility within the data center 
> while periodically use cases appear (such as the one you mention) where 
> traffic to be decrypted goes from internet to the internal network (or even 
> viceversa). I'm starting to understand someone who some months ago said this 
> looked like playing "whack-a-mole".
> 
> Besides, from what I understand from Steve Fenter's proposal (I may be wrong 
> because I have seen only the slides) , they seem to go for non-visible TLS 
> 1.3 connections from the client to the external layers of the network, and 
> visible TLS 1.3 connections within their internal network. This would match 
> the idea of "visibility only within the datacenter" but in my opinion it 
> requires a finalization of the external tunnel and creation of a new internal 
> one. At that point you obviously have the clear text and you could move your 
> monitor tasks to that point.
> 
> So maybe it's because the presentation is obsolete or because I lack context 
> but... no, I don't think those specific slides are a valid example today.
> 
> 
> De: TLS <tls-boun...@ietf.org> en nombre de Jim Reid <j...@rfc1035.com>
> Enviado: sábado, 24 de marzo de 2018 16:56
> Para: Dan Brown
> Cc: tls@ietf.org
> Asunto: Re: [TLS] Breaking into TLS for enterprise "visibility" (don't do it)
> 
>> On 19 Mar 2018, at 15:18, Dan Brown <danibr...@blackberry.com> wrote:
>> 
>> PS: I never directly worked on enterprise security (usually, I just think 
>> about the math of basic crypto primitives), but I don't recall hearing about 
>> such a "visibility" feature in the enterprise security work of colleagues 
>> (whom I do _not_ speak for), e.g. one system used forward-secure ECMQV to 
>> establish a connection between smartphones and the enterprise network.
> 
> Hearsay anecdote is not evidence. :-)
> 
> There are use cases in enterprise networks, notably in banking and finance. 
> Some of these were presented to the TLS WG. [See Steve Fenter’s presentation 
> at IETF97.] However the WG did not reach consensus on adopting the relevant 
> drafts as work items.
> 
> 
> ___
> 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Steve Fenter]

I know of a number of large enterprises in verticals including financial, 
health care, retail, and government, across multiple countries, who are using 
packet payload inspection within their data centers.  Most of these enterprises 
are reluctant to step forward in a public forum and reveal their internal 
network structure and their internal security and monitoring practices. This 
gives the false impression that out of band decryption of TLS is not a big 
deal. It is in fact mission critical to a significant number of large 
enterprises.

I have been saying to anyone who will listen that the IETF needs a private 
forum for enterprises, to enable them to come forward and discuss their real 
requirements. Without this input the IETF is trying to architect and engineer 
solutions without knowing the complete set of requirements, at least on the 
enterprise side.  This results in sub-optimal design decisions (from an 
enterprise perspective), which in this case will break mission critical 
enterprise monitoring and troubleshooting systems.

We've already experienced what a rollout of TLS 1.3 will be like, at more than 
one enterprise, when certain vendors decided to move Diffie Hellman ciphers to 
the top of their priority list on a code upgrade. This caused severity one 
outages of critical monitoring systems.  This means that critical applications 
depend on these monitoring systems, and if the monitoring system is down the 
application is completely down. This is not the outcome we want when TLS 1.3 is 
rolled out, but it is what we are headed for. Enterprise monitoring should be 
tested as part of the operational TLS 1.3 testing before TLS 1.3 is approved as 
a standard, and TLS 1.3 should not be approved if enterprise monitoring breaks.

The only other option being presented to enterprises is that we continue to run 
on a TLS spec that is nine years old, and then continue running it until it is 
14 to 19 years old. It makes no sense to me to put out a TLS 1.3 standard, but 
say that enterprises cannot upgrade to it.


> On Oct 19, 2017, at 5:37 PM, Christian Huitema  wrote:
> 
>> On 10/19/2017 3:30 PM, Darin Pettis wrote:
>> 
>> The amount of people currently voicing concern is likely small for two
>> reasons.  One is that everything is public and many of the "lurkers"
>> are hesitant to voice their concerns.  The second reason is that so
>> many don't know that visibility will be an issue.  They will either
>> discover this as they migrate to TLS 1.3 or as they start to encrypt
>> within their data center.  There is work to rapidly raise that
>> awareness through roundtables, conferences and other venues.
> 
> Might it be because many of these enterprises and data centers do not in
> fact see encryption as a problem? Maybe they have found ways to manage
> their applications and servers without breaking TLS...
> 
> -- 
> Christian Huitema
> 
> ___
> 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] Publication of draft-rhrd-tls-tls13-visibility-00

[Steve Fenter]

The main problem with not addressing the TLS visibility issue now is that no 
one knows when a vulnerability will be discovered in TLS 1.2 that forces 
enterprises to upgrade to TLS 1.3. We've had guarantees that TLS 1.2 and the 
RSA key exchange are going to be fine for 5 to 10 years, but nobody knows that, 
particularly in today's security environment. I've also learned that getting a 
solution in place through the IETF is a multi-year process, and then vendor 
adoption time has to be added on top of that.  Enterprises don't want to be 
caught in a position where a vulnerability is forcing us to upgrade, and we are 
starting at ground zero on a multi-year process to restore TLS visibility. We 
have to get out in front of this problem so we're not caught unprepared.

Sent from my iPad

> On Oct 20, 2017, at 11:57 AM, "Salz, Rich"  wrote:
> 
> 
> 
>So it sounds like we are in agreement that continuing to use TLS 1.2 is 
> not a viable long term  alternative.  
> 
> 
> Long-term is a subjective term, and using it can lead to misunderstandings.
> 
> Based on current and previous actions around SSL and TLS versions, you can 
> use TLS 1.2 for at least five, likely at least 10, years.
> 
> 
> 
> ___
> 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-green-tls-static-dh-in-tls13-01

[Steve Fenter]

> On Jul 11, 2017, at 2:15 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 
> wrote:
> 
> 
> To add to Ted's clarification requests:
> 
>> On 11/07/17 19:39, Steve Fenter wrote:
>> Network security monitoring is not just monitoring traffic that
>> results from communications with customers and partners.  All it
>> takes is for one user to click on a phishing email and there is
>> malware inside the enterprise.  Once this happens, TLS becomes the
>> enemy, because 30% of malware is TLS encrypted, and any TLS features
>> intended to thwart payload inspection work against the enterprise.
> 
> I'd appreciate a citation for that 30% figure.

30% came from Cisco Systems at a recent Cisco Live conference.  Their numbers 
indicated 10% in 2015 and 30% today
> 
> And if you had one an estimate for how much malware does it's own
> obfuscation or home-grown crypto in addition or instead of using TLS.
> The reason to ask is that as soon as malware does that then you
> are back to analysis based on ciphertext only. From descriptions
> of advanced attack schemes, they do seem to do both when calling
> home or exfiltrating data. In which case I think your argument
> falls.

I don't have any numbers for home-grown crypto.  I would think the odds are 
better for the enterprise if they can decrypt and inspect whatever portion is 
TLS.
> 
>> Malware does not always phone home out to the Internet on day 1 of
>> infection.  
> 
> In what circumstance will malware phone home to a TLS server that
> is playing your wiretap game? That seems utterly illogical but
> maybe I'm missing a reason why someone's malware will use TLS to
> talk to a server that is controlled by the victim network as part
> of phoning home. Please clarify.

Phone home would have to be caught by an inline solution on the way out the 
Internet.  I was just suggesting that malware could be caught earlier in the 
process with multiple inspection points throughout the enterprise.
> 
> S.
> 

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