> -----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?
 
> > 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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to