Hi Karl, On 09/23/2013 05:32 PM, Karl Malbrain wrote: > > >> -----Original Message----- From: Stephen Farrell >> [mailto:[email protected]] Sent: Friday, September 20, 2013 >> 12:09 To: Karl Malbrain Cc: [email protected]; [email protected] >> Subject: Re: [perpass] New Version Notification for >> draft-cooper-ietf-privacy- requirements-00.txt >> >> >> >> On 09/20/2013 07:50 PM, Karl Malbrain wrote: >>> "Note that this is contingent on practicality - if some personal >>> data really has to be sent in clear for a protocol to be able to >>> operate, and even opportunistic encryption is not possible, then >>> a standards- track protocol that does not define how to protect >>> that data will be consistent with this BCP. The IETF will have >>> to decide in such cases whether standardizing that protocol >>> benefits the Internet or not." >>> >>> >>> 1. Is the value of a personal public key considered "personal >>> data"? In TLS client authentication, these keys are requested. >> >> I doubt there's any data-protection regulator views on that (TLS >> client-auth being so rare on the public Internet) but basically, >> I'd say yeah, its an identifier that generally won't change for >> extended periods. That's one of the motivations for doing TLS 1.3 - >> to hide such handshake data for example. >> > > Apart from the desirability of encrypting the personal public key > when it is sent (e.g. OE), is association with a person on a server > of a hash of the public key for subsequent authentication purposes > covered by this BCP?
Well, its not a BCP yet, its a proposal. But assuming for the moment it became a BCP unchanged, then I'd say that the protocol used to access a person's public key or public key hash from such a server would be covered by the BCP yes. >>> 2. Under the goal of MITM resistance, how can opportunistic >>> encryption provide security without authentication? I think that >>> an authentication layer on top of opportunistic encryption is >>> required. >> >> I disagree. "Security" is not a binary state of affairs. >> Opportunistic encryption without authentication can provide some >> value, esp in this context where it forces a more active and >> presumably expensive and more likely detected attack if you want to >> pervasively monitor everyone. > > I think that a security evaluation should be broken down into > individual attributes, each of which can be evaluated yes/no. > Resistance to MITM attack for example. Resistance to passive > surveillance is another attribute. Yes, those are different things. And there can be a tension between them. S. > > Karl Malbrain _______________________________________________ perpass > mailing list [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
