On 10/19/2017 05:30 PM, Darin Pettis wrote:
>
> The question has been raised: "Why address visibility now?" The
> answer is that it is critical that the visibility capability is
> retained. It is available today through the RSA key exchange
> algorithm. We understand that the issue was raised l
On 10/19/2017 3:30 PM, Darin Pettis wrote:
> The amount of people currently voicing concern is likely small for two
> reasons. One is that everything is public and many of the "lurkers"
> are hesitant to voice their concerns. The second reason is that so
> many don't know that visibility will be
On Thu, Oct 19, 2017 at 12:27 PM Salz, Rich wrote:
> We disagree.
>
> Being able to block traffic is much less effort than pretending to be
> another identity.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
Firs
We disagree.
Being able to block traffic is much less effort than pretending to be another
identity.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Oct 19, 2017, at 1:12 PM, Blumenthal, Uri - 0553 - MITLL
wrote:
> If those middleboxes already have sufficient alternative options, why do we
> spend time discussing this draft? Why do we need to add yet another
> alternative for them?
Indeed, if this proposal were equivalent to CA forcing,
If those middleboxes already have sufficient alternative options, why do we
spend time discussing this draft? Why do we need to add yet another alternative
for them?
Regards,
Uri
Sent from my iPhone
> On Oct 19, 2017, at 13:08, Paul Turner wrote:
>
>
>
>>
>> Subverting one CA cuts across
>
> Subverting one CA cuts across a large scale of Internet traffic and might be
> noticed or can be routed around.
With respect to "be noticed", forcing clients to opt-in seems like it would
clearly be noticed. My understanding was that you were saying that the
middlebox could block traffi
➢ Can you explain the comparison that I brought up regarding trusting the
CA? That is related to " the client’s willingness to let their traffic be
intercepted".
Subverting one CA cuts across a large scale of Internet traffic and might be
noticed or can be routed around. Cert
>
> 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 interce
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 intercepted. The tw
>
> 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
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 the servers t
>
> 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 the
On 19/10/17 15:16, Paul Turner wrote:
>
>
>> -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
> I didn’t say easy, I said ‘easier’
>
Can you explain how it is easier?
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 t
> -Original Message-
> From: Salz, Rich [mailto:rs...@akamai.com]
> Sent: Thursday, October 19, 2017 10:22
> To: Paul Turner ; Paul Turner
> ; Kaduk, Ben ;
> tls@ietf.org
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
>
> > Can you explain how nationwide wiret
> Can you explain how nationwide wiretapping is going to be easy with this
> plan? Again, EVERY server owner will need to opt-in.
I didn’t say easy, I said ‘easier’
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Martin,
sorry for taking so long to replay.
> On 18/10/2017, 09:08, "Martin Thomson"
> wrote:
>
> On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) wrote:
> > This is quite similar to the trial and error / heuristic that I was
> > mentioning in [1].
>
> You didn
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Salz, Rich
> Sent: Thursday, October 19, 2017 10:15
> To: Paul Turner ; Kaduk, Ben
> ; tls@ietf.org
> Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
>
>
> ➢ I guess the basic question I
> -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 18/10/17 18:41, Benjamin Ka
➢ I guess the basic question I'm asking is that if a third party is so
powerful that they can do what you describe, aren't they going to force an even
more effective method (trusting their CA so that they can terminate the
connection as a middle man) on clients so that they don't have to co
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 c
Hiya,
On 18/10/17 18:41, Benjamin Kaduk wrote:
> P.S. I agree with Rich; can we try to defer these conversations until
> after 1.3 is actually published?
FWIW, I also think it'd be a good plan if the chairs
did that. I'm happy to oppose these ideas any time,
but later is better than now, given t
23 matches
Mail list logo
