Most Enterprises do have well developed logging collection and parsing infrastructures (e.g. Splunk, etc.). But they are one of many tools needed to effectively manage complex corporate networks and applications. They cannot fully replace network monitoring any more than network monitoring can replace logging, IMHO.
I do agree that it would be optimal for all perspectives and requirements to be introduced as early in the process as possible. Hence one of the motivations for attempting to get Enterprises more active in IETF, in general. From: Watson Ladd [mailto:watsonbl...@gmail.com] Sent: Monday, July 10, 2017 4:11 PM To: Ackermann, Michael <mackerm...@bcbsm.com> Cc: Polk, Tim (Fed) <william.p...@nist.gov>; tls@ietf.org Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... On Jul 10, 2017 8:46 AM, "Ackermann, Michael" <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> wrote: +1 !!! And For the enterprise situations, we typically own, operate and manage the involved “Facilities”: The Servers The Applications The Networks The Keys The Data and in Many cases the clients as well Given the above scenario, I do not understand how this can be construed as “Wiretapping”. 2804 seems to make this clear. What Enterprises want in this space, is the ability to continue to have access to their aforementioned facilities, to perform diagnostics, monitoring and security functions. (i.e. continue to effectively operate and manage our networks). Although I believe the Matt Green draft proposes a very good, viable and well thought out solution for TLS 1.3, I suspect most of us are open to different or better solutions, if such exists or can be conceived. There seems to be good discussion, requirements and ideas on both sides of this issue, albeit in sharp disagreement in many cases. Such critical colloquy, with significant long term impact, should not be prematurely terminated, IMHO. Finally an editorial comment from those of us TRYING to get Enterprises involved at IETF. We finally have some interest and engagement from Enterprise perspectives. Killing discussion on this issue, which is clearly important to Enterprises, will send the message that IETF did not really want this input or feedback. I hope this is not the case. One vertical is not all enterprises. Plenty of companies can trace requests via logging systems and do not need mirroring for diagnostics. Perhaps if we weren't faced with a last minute request to include static ciphersuites things would be different. But the technique exists and can be used regardless of approval. (Have you considered Dual EC+extended random?) The problem->box model has never been well-suited for the internet. There are serious policy considerations here and a long agenda for this WG. Stopping discussion is not about ignoring the problem: it's stopping a discussion going nowhere from eating up all the bandwidth. From: TLS [mailto:tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>] On Behalf Of Polk, Tim (Fed) Sent: Monday, July 10, 2017 9:54 AM To: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... First, I do not see this as a “wiretapping discussion” based on my reading of 2804, although others may disagree. Second, I believe that this discussion should go forward based on several points: 1. this proposal does not involve any changes to the bits on the wire specified in the TLS 1.3 document 2. this proposal offers significantly better security properties than current practice (central distribution of static RSA keys) 3. alternative solutions with significantly worse security properties are also feasible under TLS 1.3, and I would like to avoid them! We should be in the business of developing pragmatic, interoperable solutions with appropriate security properties. Balancing cryptographic security with other security requirements to achieve such solutions should be an acceptable path, and pursuing this work in the TLS working group gives the IETF the best opportunity to influence these solutions. 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<mailto: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
