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

From: Karl Malbrain <[email-masked]>
Date: Fri, 20 Sep 2013 18:50:17 +0000

"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.

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.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2013 20:08:50 +0100

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.

> 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.

S.

> 
> 
> 
> 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Scott Brim <[email-masked]>
Date: Sat, 21 Sep 2013 13:42:29 -0400

> for doing TLS 1.3 - to hide such handshake data for example.

If you are signing something then you are explicitly deciding to reveal the
related information. You made the decision to release it into public view,
so your privacy is not violated. You need to be doubly careful of other
correlatable info. However, if you are not using a particular public key
generally, but restricting its use, then yes it should be kept within the
intended scope of confidentiality.

Scott

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 23 Sep 2013 05:22:25 -0400

> On Sep 21, 2013, at 13:42, Scott Brim <[email-masked]> wrote:
> 
> If you are signing something then you are explicitly deciding to reveal the related information.

You can certainly sign something intended for an audience that is less than public, so this doesn't hold.

best, Joe

--
Joseph Lorenzo Hall
Senior Staff Technologist
Center for Democracy & Technology
https://www.cdt.org/

---

From: Scott Brim <[email-masked]>
Date: Mon, 23 Sep 2013 09:09:22 -0400

Joe, yes, that's what I meant in the rest if the message. Story if it
wasn't well constructed, I'm using a phone for mail.