I have been saying this for five or six year now, that is hardly gung ho. And I have discussed it at length with the people behind the original end to end model.
What I am saying is that the design of a security protocol needs to come from an analysis of risks and of the constraints imposed by users, legacy technology, etc. If the approach that happens to minimize residual risk in practice is end to end, then fine, go with it. But 'must be end to end' has no place in a requirements document. Remember that SSL was very different from the designs that I proposed, EKR and Shiffman proposed and everyone in IETF land was considering. It broke with the current dogma in very significant ways. Now in retrospect, those breaks turn out to have been critical for the success of SSL. On Thu, Feb 16, 2012 at 1:16 PM, Nico Williams <[email protected]> wrote: > On Thu, Feb 16, 2012 at 8:13 AM, Phillip Hallam-Baker <[email protected]> > wrote: >> That works really well in the O/S world because in practice you can't >> stop a policy enforcement point from being a potential point of >> failure. The reason I dislike the peering model is that instead of one >> single point of failure you end up with fifty single points of >> failure. >> >> If Alice has her private key on every device that can read email then >> the loss of any one of those devices exposes her key and all the >> emails. > > You seem gung-ho on abandoning the end-to-end model. I understand the > reasoning, and in the case of e-mail accept it fully, but I don't > understand why we can't have a hybrid in the web case. A hybrid uses > !end-to-end to security bootstrap end-to-end security. > > Note also that if all users get personal domainnames, like you and I > and another .01% of users, then we can have end-to-end secure e-mail > between personal domains once we boostrap end-to-end relationships > between them (a big caveat, that, because most likely there will be a > multi-hop PKI trust path only, certainly to begin with). The ends > here would be servers in closets, sure, but they are suitable ends > because they are the users' servers, not some other organization's. > > Nico > -- -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
