Re: [ietf-privacy] [perpass] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt

Hi Karl,

On 09/23/2013 05:32 PM, Karl Malbrain wrote:
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, September 20, 2013
>> 12:09 To: Karl Malbrain Cc: acooper@cdt.org; perpass@ietf.org 
>> 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 perpass@ietf.org 
> https://www.ietf.org/mailman/listinfo/perpass
> 