Ted Your first sentence illustrates the disconnect between the Enterprise perspective and what many at IETF are saying. That being the unencrypted stream is available to the endpoints. IT IS NOT. When you run a packet trace at the endpoint, you will see encrypted payloads and will need the keys to decrypt. So you can collect packet trace information at thousands or nodes, or you can collect packet traces from network taps. You still need the keys to derive meaningful diagnostic and monitoring information.
People than run and manage networks are PAINFULLY aware of this fact. This is why we need what this draft proposes. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Saturday, July 15, 2017 4:06 AM To: Dobbins, Roland <rdobb...@arbor.net> Cc: IETF TLS <tls@ietf.org>; Matthew Green <matthewdgr...@gmail.com> Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01 I think that your first and third points are actually non-sequiturs: the unencrypted stream is available to the entities controlling either endpoint, not just the log. There is no technical reason that in-flight capture is required to address those two points. Regarding your second point, this seems to be the real key that is motivating you to make the first and third points. If I may paraphrase, the problem you are attempting to address is that in some situations two sub-organizations both of which are in principle responsible to a larger organization nonetheless are unable to cooperate due essentially to a failure by one sub-organization to take seriously the responsibilities of the other sub-organization, and the failure of the organization to which they are both subordinate to successfully encourage cooperation on the part of the intransigent sub-organization. Did I paraphrase that correctly? On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland <rdobb...@arbor.net<mailto:rdobb...@arbor.net>> wrote: > On Jul 15, 2017, at 14:48, Ted Lemon > <mel...@fugue.com<mailto:mel...@fugue.com>> wrote: > > In the event that it is not feasible for an operator to obtain the plaintext > of a message without the key, isn't that because they don't control either > endpoint? First of all, what goes on the wire is often contextually different (and probatively so) from what's recorded in abstract log files. Secondly, administrative divisions within a single organization often impede cooperation between those tasked with securing & troubleshooting communications and those who 'own' the assets in question. Thirdly, for both security & troubleshooting applications, the hard requirement is for real-time visibility & possible intercession, not ex post facto analysis. ----------------------------------- Roland Dobbins <rdobb...@arbor.net<mailto:rdobb...@arbor.net>> 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
