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 <paul.tur...@venafi.com> wrote:
>
>
>
>>
>> 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 traffic. That seems in conflict with your statement
> that they can be "routed around".
>
>> Certificate transparency helps prevent a
>> single CA from being coerced into misissuance.
>
> It seems like a middlebox that is able to deny traffic (has that level of
> power, would simply use their own CA and force trust of that)
>
>> With this extension, someone
>> doesn’t have to coerce a CA or force victims to trust a new CA. Instead they
>> have to gain the cooperation of the origin(s) they are interested in.
>
> Gaining the cooperation of the servers (origins) seems relevant. If they get
> the cooperation of the servers, they can simply get the data directly from
> them. But, again, they also have to get the cooperation of the clients.
>
> If a middlebox has sufficient power to block traffic, force clients into
> opting in, and coerce servers into opting in, it seems like they have
> sufficient alternative options that are of equivalent effort ("ease").
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
