On Thursday, 19 October 2017 19:12:11 CEST 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?
so that they benefit from standardisation, network effects and be fiscally
responsible!
</devils advocate>
> 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
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
