I certainly agree that any draft-*-00 almost certainly needs heavy doses of IETF input. But I’m actually failing to understand where Kathleen’s suggestions are trying to go. This draft is trying to make general points that are orthogonal to any particular technology, including:
- Positive & negative privacy failures are asymmetrically harmful - the right choices are hard to make, so just don't ask inexpert uses to make them, - the cost of privacy technologies is monotonically falling I think this draft is most useful if it can restrict itself to saying things that are widely true across the tech-trade-off spectrum. So, while transport encryption is one of the most widely-used privacy technologies, the points above are also true (I think) when applied to entirely different things like message signing and server-side encryption-at-rest. Sorry, I’m entirely failing to think of what this draft might say about OS. The admirable Let’s Encrypt work is I guess evidence of the monotonically-decreasing-cost premise. SPs are being asked to deploy a variety of privacy technologies,and I’ve observed recurring patterns of muddy thinking in their pushbacks; this draft is an attempt to curate the arguments that are useful in these discussions, independent of any particular flavor of privacy technology. On Sat, Mar 14, 2015 at 10:51 AM, Kathleen Moriarty < [email protected]> wrote: > Hey, > > As the draft stands now, it needs more detail and contributions to be > helpful. If folks are interested, please contribute. > > IMO, It would have to be broken down further in terms of the types of > encryption and cost/benefits. > > For instance, KMIP (yes, I know this is not an IETF standard) is on an > upswing. So is the general statement on cost of PKI specific to transport > encryption? How does OS factor into this and help with the cost/benefit? > We should know more soon through efforts like Let's Encrypt and Fedora > having IPsec unauthenticated tunnel mode on by default (I think in version > 23). > > What requests are SPs getting in regard to encryption (transport, > application data or data at rest) and what are the hurdles? > > Operators may not be hanging out on this list, so maybe a post with the > types if info you are looking for to build this out should go to opsawg > with a pointer to the list you think this should be discussed on. > > Thanks, > Kathleen > > Sent from my iPhone > > > On Mar 13, 2015, at 5:28 PM, Stephen Farrell <[email protected]> > wrote: > > > > > > Folks, > > > >> On 13/03/15 20:52, Tim Bray wrote: > >> This was about to expire so I was going to refresh it but uploader is > >> closed of course. See > >> https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html > >> > >> Just a reminder that if this group wants to do anything in this space, > my > >> editorial services are available. > > > > I'd be interested in opinions as to how/whether we ought process > > this. > > > > Ta, > > S. > > > > > >> > >> > >> > >> _______________________________________________ > >> perpass mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ > > perpass mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/perpass > -- - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
