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

From: Karl Malbrain <[email-masked]>
Date: Mon, 23 Sep 2013 16:32:57 +0000

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, September 20, 2013 12:09
> To: Karl Malbrain
> Cc: [email-masked]; [email-masked]
> 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?
 
> > 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.

Karl Malbrain

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2013 09:26:00 +0100

Hi Karl,

On 09/23/2013 05:32 PM, Karl Malbrain wrote:
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Friday, September 20, 2013
>> 12:09 To: Karl Malbrain Cc: [email-masked]; [email-masked] 
>> Subject: Re: [perpass] New Version Notification for
>> draft-cooper-ietf-privacy- requirements-00.txt
>> 
>> 
>> 
>>> "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.
>> 
>> 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-masked] 
> https://www.ietf.org/mailman/listinfo/perpass
>