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