Re: [TLS] Industry Concerns about TLS 1.3

[Brian Sniffen]

nalini.elk...@insidethestack.com writes:

> [ Unknown encryption status ]
> [ Unknown signature status ]
>
>
>
>>>
>>> What I am saying,  in relation to your "Delivering a stable product"  
>>> comment is that over time various industries have learned what it takes to 
>>> "Deliver a stable product".    We did not >>want to invest millions in 
>>> these debugging networks.  But  we learned the hard way,  that it was 
>>> necessary.
>>> I am not a member of the banking coalition that started this subject,  nor 
>>> of the banking industry at all,  but I certainly understand their 
>>> perspective and am concerned about  the same >>unmanageable future they 
>>> described.
>
>>Do  Akami, Cloudlflare and Google magically not have these problems?
> It would be very interesting to get the network diagnostic and
> operations people (rather than the architects) of the above companies
> involved in this conversation.

Hi, technical person most directly responsible for incident response and
urgent debugging here.  We modify endpoints to get what we need.  We did
have taps that relied on knowing the RSA Kx secret... but haven't used
them in about a decade.

I think the banks have an answer not available to the global passive
adversaries: modify the server or client to use a fixed ECDH share, then
use tech much like their current choices.  It'll take a while to
develop, but nobody in that environment plans to move to TLS 1.3 for
operational systems any time soon anyway.

-Brian


> Also, you know, companies don't really enjoy spending money on network 
> diagnostic products which might be considered overhead.   So, if they are, we 
> might do them the courtesy of not thinking that they are foolish to do so.   
> Why don't we listen to each other?   I know at IETF, I often hear that we 
> don't get enough operators to comment and give feedback.  Well, here you have 
> some.  It may be that these companies have problems that are different from 
> Google's (just as an example).
> Isn't our goal to have the best standards possible?   Any organism (including 
> the IETF), needs feedback to thrive.
> Nalini
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> -Original Message-
>> From: Jeffrey Walton [mailto:noloa...@gmail.com]
>> Sent: Friday, September 23, 2016 10:55 AM
>> To: Ackermann, Michael 
>> Cc: BITS Security ; tls@ietf.org
>> Subject: Re: [TLS] Industry Concerns about TLS 1.3
>>
>> On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael  
>> wrote:
>>> From the perspective an Enterprise that runs these applications and has 
>>> invested HEAVILY in the debugging networks.
>>>
>>> The reason we are debugging these networks is so that "The 5-6 order of 
>>> magnitude of folks using them"  will have good service.  If they do not,  
>>> they will consider competitors and/or generate a litany service calls or 
>>> complaints.        I.E.    When these "Folks"  are slow or not working they 
>>> are just as unhappy as we are.
>>>
>>
>> Isn't that the market operating as expected? Those who deliver a stable 
>> product at a competitive price are rewarded, while those who fail to deliver 
>> or deliver at an unreasonable cost are not? (Some hand waiving).
>>
>> If all providers failed to deliver or delivered an inferior product, then it 
>> might indicate a major course correction is needed. But I don't think that's 
>> the case here.
>>
>> Jeff
>>
>>
>> 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
>
>
>
> -- 
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> ___
> 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
>
>
>
>>>
>>> What I am saying,  in relation to your "Delivering a stable product"  
>>> comment is that over time various industries have learned what it takes to 
>>> "Deliver a stable product".    We did not >>want to invest millions in 
>>> these debugging networks.  But  we learned the hard way,  that it was 
>>> necessary.
>>> I am not a member of the banking coalition 

Re: [TLS] Industry Concerns about TLS 1.3

[Ilari Liusvaara]

On Thu, Sep 22, 2016 at 03:29:42PM -0400, Dave Garrett wrote:
> 
> Yes, all of these other channels are protected using TLS... which you
> do not control in any way. Also, many sites/services already prioritize
> FS cipher suites, so the deprecation of plain RSA key exchange doesn't
> actually affect the vast majority of people. (e.g. Facebook & Twitter
> both prefer ECDHE with NIST P-256) Within this very argument is
> already the argument that supervision at endpoints is required here.
> he security on the pipe is irrelevant. I don't see how you can make a
> point to bring this up but think keeping plain RSA KE suites is a
> useful solution.

Well, if you have client and server that both have RSA KE enabled
(even if not preferred), you can do something like this:

- Intercept ClientHello. Strip any FPS ciphersuites and any associated
  extensions, strip EMS and ALPN but keep client_version and
  client_random the same.
- The server will select RSA KE.
- Intercept Certificate message and replace it with MITM cert.
- Intercept ClientKeyExchange decrypt the key and re-encrypt with the
  original server key.
- Compute the session key and log it.
- Intercept the ClientFinished message and replace it with fixed
  version.
- Intercept the ServerFinished message and replace it with fixed
  version.
- Get off the active path, becoming passive.
- Log the data transfer on the connection, and later decrypt it if
  desired.

The keys will match, because they only depend on randoms (which
were preserved) and the encrypted secret (which was preserved too).
The EMS was stripped because it would break this.

The MITM proxy knows the secrets needed to fix the Finished messages.

Preferring FS won't help, because MITM proxy can downgrade the
crypto negotiation.


(And it is not like one can easily get the keys without either
replacing the cert or knowing the RSA private key corresponding to
it).




-Ilari

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

Re: [TLS] Industry Concerns about TLS 1.3

[Ackermann, Michael]

What I mean is that we have Many MITM solutions today and they are able to be a 
good source for troubleshooting/diagnostics, in limited situations or 
perspectives.This lack of scope, depth and detail are what drove us to 
install the packet collection infrastructures (debugging networks I think some 
are saying).

Some of the issues we have found include: 
* Level of detail is not sufficient.
* Inherent tools are not sophisticated.  
* Data is difficult to share.   
* MITM management systems frequently do not "Play well" with overall management 
frameworks and other tools.  
* Problems take longer to resolve.  
* Depending upon the level of information logged on an MITM platform,  the 
inherent  processing can (and frequently does), create performance problems on 
the MITM and can change conditions,  obfuscating the original issue. 
* MITMs are not usually configured to record, retain, archive or manage large 
amounts of diagnostic data.  
* A MITM platform frequently has a very limited vision of the overall session 
path.   Or,  there may be multiple MITM's involved in a session path.Which 
one has the best view?  Which one(s) should you focus on?  
* AND,  as you said,  the more MITMs you add, the more latency and complexity 
you are forced to deal with.As a network diagnostic person this approach 
can actually make your responsibilities more difficult and  less achievable. 
* The information collected is usually not granular enough to perform network 
diagnostics for those situations that require it. 
* One key initial piece of information in troubleshooting is to determine if 
the source of the problem is in: the Client, the Network or the Server.   
MITM's are rarely able to provide insight into this critical and time sensitive 
determination.  
* in general diagnostics are made more difficult with this approach.  Multiple 
sessions and possibly interfaces may need to be traced and the MITM can further 
confuse things by acting as a router and/or a nat and/or a Load Balancer.   As 
someone who deals with these types of additional complexities every day,  I 
would like to see fewer MITMs  rather than more.  


My organization uses the MITM diagnostics and management systems, and like most 
point solutions they are a valuable facet of our diagnostic arsenal,  but 
because of the manifold shortcomings (some of which are listed above),  they 
are not a central focus and are not a viable initial focal point or  suitable 
overall point of triage. Triage may dictate the use of the MITM 
diagnostics,  but MITM troubleshooting/diagnostics would not be an effective 
method on its own,  for most situations/issues that exist in today's complex 
multi-tier applications.  

My job is to make things work and fix them ASAP when they don't.   While I 
fully understand the need for effective security,  I hope those on the security 
side  would conversely understand the need to make things work, perform well,  
and quickly diagnose problems when they do not.  I am often reminded of a 
colleague who states (jokingly I think)   "The ultimate security is where no 
data flows and nothing works". I hope this is not the direction we are 
heading and that some form of compromise will be forthcoming between these two 
discrete factions with differing perspectives.  





-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Pawel Jakub Dawidek
Sent: Saturday, September 24, 2016 2:54 AM
To: tls@ietf.org
Subject: Re: [TLS] Industry Concerns about TLS 1.3

Hello.

As a vendor of one of those MITM proxy solutions for TLS inspection I'd be 
grateful if you could be more specific about the "scope, depth and detail" that 
is not delivered by such solutions, so we can have discussion whether this is 
something we can address or not and if not, maybe we can come up with some 
alternative solutions before we give up.

By doing MITM we increase latency, even if very little, that's inevitable. But 
can you really avoid doing MITM TLS inspection?
In my opinion, no. Let me elaborate.

Of course the amount of TLS traffic is growing rapidly (which is a good
thing) thanks to many "contributions":
- Server Name Indication extenstion,
- Edward Snowden,
- Free certificates (eg. Let's Encrypt),
- HTTP 2.0.

Because of that, every corporate network needs visibility inside TLS traffic 
not only incoming, but also outgoing, so they can not only debug, but also look 
for data leaks, malware, etc.

Customers are increasingly aware of all this and it is not a question of MITM 
incresing latency, because it has to be done, the more important is to make it 
in a decrypt-once-feed-many fashion, as they have multiple solutions in place 
to analyze the traffic for different reasons.

And when you do data leak prevention or malware detection you want to be in the 
middle so you can terminate the session as quickly as possible.

I don't want to say that Forward Secrecy comes at no price. It makes 

Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

On Sat, Sep 24, 2016 at 09:31:51PM +1000, Martin Thomson wrote:
> On 24 September 2016 at 19:17, Ilari Liusvaara  
> wrote:
> > It occured to me that certain extensions might be considered to be per-
> > chain. Like e.g. type of the certificate. Where do extensions like that
> > go? Always to the extension block of the first certificate (except that
> > might cause somewhat of a cyclic dependency in parsing)?
> 
> The type of which certificate?  The end-entity?  Seems like that
> belongs with the end-entity cert then.

I mean equivalent of the client_certificate_type/server_certificate_type
extensions.

And the way those extensions are defined, those scope the entiere chain.

E.g. There was some discussion about "subcerts"[1]. One way to add those
would be as a new certificate type.

... Or are new certificate types like new CLASSes in DNS: Heavy objects
dropped by bad idea fairy? :->


But in the future, there might very well be new extensions that are
scoped to certificate chain and not and individual certificate. And
those can't be put into EncryptedExtensions if server can send multiple
certificates (like it can in post-handshake auth extension) or if
client needs to send one.


[1] The usecases can't be practically accomplished today: The mode of
operation is just plain alien to X.509.


-Ilari

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

Re: [TLS] Proposed Change to Certificate message (#654)

[Ilari Liusvaara]

On Fri, Sep 23, 2016 at 11:05:10PM +, Nick Sullivan wrote:
> Thanks for the suggestions. I've restructured my PR to include an array of
> SingleCertificate objects in the Certificate structure.

It occured to me that certain extensions might be considered to be per-
chain. Like e.g. type of the certificate. Where do extensions like that
go? Always to the extension block of the first certificate (except that
might cause somewhat of a cyclic dependency in parsing)?

And then there is the user_mapping. I presume mechanism like this is to
be used to transport it (avoiding need to mess with new handshake
messages and such.
 
> Ilari: I agree that the post-hanshake auth mechanism as currently described
> is a bit lacking, but I'd like to sort this out first.

Well, more like I was annoyed at having to implement that at all and the
fact that it requires remembering a hash state (which may be a quite
harsh requirement in some cases).


-Ilari

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