Re: [TLS] chairs - please shutdown wiretapping discussion...

Stephen, You have referenced RFC 2804, which states the following in section 3: "For the purposes of this memo, the following definition of wiretapping is used: Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a

Re: [TLS] Is there a way forward after today's hum?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, July 20, 2017 07:51 To: Paul Turner <paul.tur...@venafi.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's h

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 07:54 To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@

Re: [TLS] Is there a way forward after today's hum?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton Sent: Thursday, July 20, 2017 05:58 To: tls@ietf.org Subject: Re: [TLS] Is there a way forward after today's hum? Apologies for not replying "in thread" on this occasion, for noob reasons... but here's the specific comment from

Re: [TLS] Is there a way forward after today's hum?

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, July 20, 2017 07:25 To: Paul Turner <paul.tur...@venafi.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? P

Re: [TLS] Is there a way forward after today's hum?

Thanks for your response. Response to one of your comments below. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Robin Wilton Sent: Thursday, July 20, 2017 09:45 To: Paul Turner <paul.tur...@venafi.com>; tls@ietf.org Subject: Re: [TLS] Is there a way forward after today's hum? H

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Tom Ritter Sent: Thursday, July 20, 2017 10:44 To: Yoav Nir Cc: IETF TLS Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2017 at 01:53, Yoav Nir <

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 10:58 To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, July 20, 2017 08:22 To: Paul Turner <paul.tur...@venafi.com>; Ted Lemon <mel...@fugue.com> Cc: Robin Wilton <wil...@isoc.org>; <tls@ietf.org> <tls@

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: Tom Ritter [mailto:t...@ritter.vg] Sent: Thursday, July 20, 2017 11:20 To: Paul Turner <ptur...@equio.com> Cc: Yoav Nir <ynir.i...@gmail.com>; IETF TLS <tls@ietf.org> Subject: Re: [TLS] Is there a way forward after today's hum? On 20 July 2

Re: [TLS] Is there a way forward after today's hum?

-Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Martin Rex Sent: Thursday, July 20, 2017 09:29 To: Russ Housley Cc: IETF TLS Subject: Re: [TLS] Is there a way forward after today's hum? I'm sorry, Russ, but I think this

Re: [TLS] datacenter TLS decryption as a three-party protocol

Of course, this is precisely the point. All your proposal does is complicate the process of sharing sessions with a third-party: it doesn't stop an endpoint from surreptitiously doing evil. Is the objective to have the protocol prevent an endpoint “surreptitiously doing evil”? Also, can

Re: [TLS] datacenter TLS decryption as a three-party protocol

It's fascinating that people cannot seem to stop picking at the scab remaining after draft-green. I really think we'd be wiser to just let the wound heal. (And get on with the work that this WG has been chartered to do, which does not include wiretapping.) Sorry to ask for this so late in

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell > Sent: Thursday, October 19, 2017 09:07 > To: Benjamin Kaduk ; tls@ietf.org > Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 > > > Hiya, > > On

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich > Sent: Thursday, October 19, 2017 10:15 > To: Paul Turner <paul.tur...@venafi.com>; Kaduk, Ben > <bka...@akamai.com>; tls@ietf.org > Subject: Re: [TLS] Publication of d

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ben, In the scenario you outlined below, it seems the third party has significant control over the communications of the clients (e.g. national border firewall). In addition, based on your description, it seems they are intent on ensuring that not communications occur unless they can view the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> -Original Message- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Thursday, October 19, 2017 10:22 > To: Paul Turner <ptur...@equio.com>; Paul Turner > <paul.tur...@venafi.com>; Kaduk, Ben <bka...@akamai.com>; > tls@ietf.org > Subject:

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> > There’s no way to limit it to the use-case it was putatively intended for. We > now have a signaling mechanism that says “allow interception.” Firewalls can > drop connections where the client doesn’t send that extension. Therefore they > can force only tappable TLS traffic. This makes

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> > With this extension, any middlebox anywhere can drop traffic that is not > tappable. Regardless of who controls the clients and servers, we are now > enabling entities to block traffic unless you acquiesce. For example, an > inflight > wifi could use this. Maybe, ultimately, many/most of

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

> > They can already block traffic based on IP address. That’s single-point > blocking. Being able to block based on the client’s willingness to let their > traffic be interception is a whole additional class and it also indicates > that the > client is willing to let their traffic be