hi Alissa, On 23 Sep 2013, at 16:32 , Alissa Cooper <[email protected]> wrote:
> Hi Brian, > > Thanks for your comments. > > On Sep 23, 2013, at 3:40 AM, Brian Trammell <[email protected]> wrote: > >> hi Stephen, all, >> >> (copying ietf-privacy as requested in the draft) >> >> I've read the draft; it's a very good and welcome start at extending 6973 to >> a set of concrete recommendations for protocol design. I've got one comment >> on opportunistic encryption, though: >> >> In section 3, halfway down the page: "...at minimum, opportunistic >> encryption needs to be well-defined for almost all new IETF standards track >> protocols." >> >> I understand the rationale behind that "almost", but the lines around it >> will need to be very clearly drawn. On brief consideration, I cannot think >> of a single _new_ protocol for which opportunistic encryption shouldn't be >> the default, for reasons other than interoperability with an existing >> protocol that has a significant installed base. Even in such cases, I think >> it would be useful to be very clear that communication in the clear for >> interoperability is an exception, a "legacy" mode, "to be deprecated", or >> other not-very-happy-sounding words that mean "we realize we're stuck with >> it in this case but that's really no excuse." > > I have not been super comfortable with the "almost" either. I've been > thinking instead of something like: > > "As a consequence, at minimum, opportunistic encryption needs to be > well-defined for new IETF standards track protocols. This requirement may be > waved only in exceptional circumstances where the protocol's utility would be > eliminated or severely diminished if opportunistic encryption were defined." This is a better version of what I've been trying to come up with. (Nit: s/waved/waived/) >> The information radiated even from protocols which have no obvious >> connection with personal data can be correlated with other information which >> can paint a very rich behavioral picture, that only takes one unprotected >> link in the chain to associate with an identity. Opportunistic encryption >> everywhere reduces the content of this radiated information, as well as >> reducing the risk of unprotected links holding some associable identifier. >> So exceptions will have to be very well justified if an aim of this work is >> protection of privacy against pervasive surveillance. > > I'm not ready to ink this on my skin, but it does seem like good text to add > to the document, with minimal tweaks. :) Now that I've seen the direction this draft is going in, I'm hoping to get back to -perpass-ppa soon, to move it more in the direction of a catalog of information radiation to look for. Cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
