As a person that supports enterprise environments, I would like to make a few points towards supporting draft utilizing static DH keys inside of enterprise perimeters:
* We need to support in-line and out of band TLS decryption in order to be able to fulfill our obligations to securely support our clients. We would have to utilize active application firewalls, IPs, IDS, End User Management and monitoring tools. * Supporting Monitoring, EUM, and Security horizontal and vertical traffic coverage inside of the DMZ would be almost impossible. In many cases relying on logs and application/ network alerts and alarms leaves many troubleshooting and monitoring aspects cumbersome and not reliable. * Men in the middle solution (such as proxy, accessibility fabrics/switches, load balancers sandwiches, ... ) adding additional processing time that would increase round trip time by 20 to over 100% (based on our internal benchmarks) That would lead to time X where X is number of application turns. How would users like it if their "favorite web site" had such an increase in response time during browsing? * On the public internet site, exploit client browsers could have a setting or warning to refuse such a TLS conversation to avoid static key usage as it was mentioned in previous communications. -----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of tls-requ...@ietf.org Sent: Tuesday, July 11, 2017 6:09 PM To: tls@ietf.org Subject: TLS Digest, Vol 156, Issue 60 Send TLS mailing list submissions to tls@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=obUyEFMB40U1YA3Vm8KOBQKwd4VQax8zip_AAct0jvk&e= or, via email, send a message with subject or body 'help' to tls-requ...@ietf.org You can reach the person managing the list at tls-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. Re: chairs - please shutdown wiretapping discussion... (Ted Lemon) 2. Re: chairs - please shutdown wiretapping discussion... (Stephen Farrell) 3. Re: chairs - please shutdown wiretapping discussion... (Yoav Nir) ---------------------------------------------------------------------- Message: 1 Date: Tue, 11 Jul 2017 17:16:31 -0400 From: Ted Lemon <mel...@fugue.com> To: Stephen Farrell <stephen.farr...@cs.tcd.ie> Cc: Christian Huitema <huit...@huitema.net>, tls@ietf.org Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: <ff3f29fc-9eaa-4092-af37-b19fb67e6...@fugue.com> Content-Type: text/plain; charset="utf-8" On Jul 11, 2017, at 4:58 PM, Ted Lemon <mel...@fugue.com> wrote: > On Jul 11, 2017, at 4:31 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie > <mailto:stephen.farr...@cs.tcd.ie>> wrote: >> I'd bet folks would invent proprietary >> ways of avoiding detection, that deviate from the "standard" >> and that perhaps make crypto worse all around. Say by deriving >> secrets from some function f(exfiltrated-secret, time, count) >> for a small counter or some such and having the decryptor of >> the wiretapped packets hunt a bit for the right key. > > Hm, well, but that would be catnip for security researchers, particularly if > it weakened the key. But yeah, you're right, that does make detecting the > attack possibly impractical aside from as a large research project. On second thought, this suffers from the same problem as the many-static-keys problem: there are too many moving parts. This requires all clocks on all servers and interceptors to be in perfect sync, not just close, or else potentially halves the performance during clock skew overlap periods. It requires every server and interceptor to implement the same algorithm. And you still have to distribute the information from which the key is derived. So again, yes, you can do this particular mitigation strategy. But it's expensive, and so nobody's going to do it if they have a better choice. It's cheaper to just re-tool to support TLS 1.3. As long as the solution isn't standard, it's only going to appeal to a _very_ limited audience, if there's any audience for it at all. E.g., consider trying to deploy something like this on a country-wide scale. You're just going to exfiltrate every key instead?it's cheaper. -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170711_558567ed_attachment.html&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=6tIu6VzbJsEfG0FdNckxZcqjUfwHtOIs4ejadxCs0Eo&e= > ------------------------------ Message: 2 Date: Tue, 11 Jul 2017 22:21:15 +0100 From: Stephen Farrell <stephen.farr...@cs.tcd.ie> To: Yoav Nir <ynir.i...@gmail.com>, Christian Huitema <huit...@huitema.net> Cc: Ted Lemon <mel...@fugue.com>, tls@ietf.org Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: <104f5108-751a-c8f5-45dc-bf5d7be26...@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" On 11/07/17 22:10, Yoav Nir wrote: > If one of the parties to a conversation cooperates with the wiretap, > this isn?t an attack. Lemme try on this one again from a different angle. In classic telephony wiretaps the carrier does the tap. There are similar situations with TLS... In hosted platforms (e.g. wordpress.com and many others) where the senders and receivers (or publishers & readers) have read and write access via PHP code and not via a shell, and cannot therefore control web or TLS configuration, the platform would be doing a wiretap if it turned this on, whilst colluding with or being coerced by some other entity that collects and later decrypts the ciphertext and packets. Are we agreed that that use-case is wiretapping via this mechanism? There are many millions of people who use such constrained hosted environments. Cheers, S. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170711_38fa13f0_attachment.asc&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=9fK4WbMTVYjcVd8WIWkHwKqZkVSsPd9526W_CEgkLkc&e= > ------------------------------ Message: 3 Date: Wed, 12 Jul 2017 01:09:02 +0300 From: Yoav Nir <ynir.i...@gmail.com> To: Stephen Farrell <stephen.farr...@cs.tcd.ie> Cc: Christian Huitema <huit...@huitema.net>, Ted Lemon <mel...@fugue.com>, TLS WG <tls@ietf.org> Subject: Re: [TLS] chairs - please shutdown wiretapping discussion... Message-ID: <a97601c6-d74f-4339-9eff-d937bd2d2...@gmail.com> Content-Type: text/plain; charset="utf-8" > On 12 Jul 2017, at 0:21, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > > On 11/07/17 22:10, Yoav Nir wrote: >> If one of the parties to a conversation cooperates with the wiretap, >> this isn?t an attack. > Lemme try on this one again from a different angle. > > In classic telephony wiretaps the carrier does the > tap. There are similar situations with TLS... > > In hosted platforms (e.g. wordpress.com and many > others) where the senders and receivers (or publishers > & readers) have read and write access via PHP code > and not via a shell, and cannot therefore control web > or TLS configuration, the platform would be doing a > wiretap if it turned this on, whilst colluding with > or being coerced by some other entity that collects > and later decrypts the ciphertext and packets. > > Are we agreed that that use-case is wiretapping via > this mechanism? > > There are many millions of people who use such > constrained hosted environments. Wordpress.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__wordpress.com_&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=Zf95oL14AEPloaHXQFOMYY6M0pRZfz3E-O2UOrH1rQM&e= > is a party to the session. It has access to the plaintext and could deliver it to whatever third party whenever they wanted. This draft may be an optimization, but the plaintext was always theirs to give. I might be deluding myself that I?m sending this email to you over TLS. In fact I?m only uploading it to gmail.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__gmail.com_&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=WqRUlHL4Shtg7zq0N-i7juYr6veb1Ig-pX59M8p9JXQ&e= > who will forward it to TCD?s server. Both servers will have access to the plaintext. Both servers can send it to a third party, or share session keys or share ECDHE private keys. Whether one party to a conversation (phone or IP) has the right to share private contents with a third party is a legal matter that varies from country to country and from state to state. I only claim that this draft does not change the fact that is true for PFS suites in TLS 1.x and for all suites in TLS 1.3, that it?s impossible to decrypt a recorded session without cooperation from either party, and that cooperation has to start *before* the session is recorded. That is not the case for POTS wiretap or for the RSA key exchange. Yoav -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170712_d1668f80_attachment.html&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=OK5RJ4SA0pK7nmpsoSNV0ssEmMo02ocAd0cFjsGrdG8&e= > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170712_d1668f80_attachment.asc&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=Lf3-sJzANnW-XVfvwiUT9jnCSJEgXMD7kz-EcOVA03g&e= > ------------------------------ Subject: Digest Footer _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=MKc8GqNkbHLFtOlhAnO20M4sBp9QaIvcEhosO-v3M9Q&s=obUyEFMB40U1YA3Vm8KOBQKwd4VQax8zip_AAct0jvk&e= ------------------------------ End of TLS Digest, Vol 156, Issue 60 ************************************ ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
