Subject: [Int-area] draft-daveor-slaac-privacy-logging-00

From: Dave O'Reilly <[email-masked]>
Date: Mon, 28 May 2018 22:19:42 +0100

Dear all,

Further to our recent discussion about draft-daveor-cgn-logging, I mentioned that I was working on another draft wherein I was hoping to present a concept that illustrates that the requirement for individual privacy and the requirement for retaining data for crime attribution purposes are not necessarily inherently in conflict with each other. I have finished the document, which is now available at:

https://datatracker.ietf.org/doc/draft-daveor-slaac-privacy-logging/

It’s an early draft but I would be very interested in any feedback from anyone who has the time or inclination to review the document.

Best regards,
daveor

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 May 2018 14:13:59 +0200

Why the history value is precisely 64bit long?  I suggest it to be 
variable length.

another point is the following:

>     Code was also developed to attempt to brute force log entries, and it
>     was noted that on the same PC used for the testing above (single CPU
>     PC with an Intel Core i7 running at 2.8GHz) attempting to brute force
>     a single log entry would be computationally infeasible (approximately
>     22,313,257 years required).  To decrypt the entire log would require
>     this same amount of time for each individual log entry.

This part is interesting.  I would rather conclude the paragraph with 
saying that the number of years required may be dramatically reduced by 
improving the algorithmic method to take advantage of local core 
multiplicity, near range IoT computing power availability and 
Internet-scale computing.

Alex

Le 28/05/2018 à 23:19, Dave O'Reilly a écrit :
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Dave O'Reilly <[email-masked]>
Date: Tue, 29 May 2018 13:59:33 +0100

Hi Alex,

Thanks for your feedback.

> On 29 May 2018, at 13:13, Alexandre Petrescu <[email-masked]> wrote:
> 
> Why the history value is precisely 64bit long?  I suggest it to be variable length.
> 

I presume you’re talking about the history value for temporary address generation? If so, you’re going to have to take that up with the authors of RFC4941 because that is what is specified in the standard.

> This part is interesting.  I would rather conclude the paragraph with saying that the number of years required may be dramatically reduced by improving the algorithmic method to take advantage of local core multiplicity, near range IoT computing power availability and Internet-scale computing.
> 
> 

Of course, you’re quite right. I haven’t coded professionally in years, nor is the hardware at my disposal particularly powerful, nor did I make any particular effort to optimise the code. The point I was trying to make, however, was that searching for a specific log entry is computationally relatively easy whereas extracting all records is computationally significantly more difficult.

I will add this comment to a list of amendments which I will make in the next draft.

Regards,
daveor

---

From: Christian Huitema <[email-masked]>
Date: Wed, 30 May 2018 10:19:58 -0700

Dave,

I like the general tone of your draft, but I am a bit concerned that it
mixes requirements and a very specific solution.

You are trying to strike a balance between your requirements and
privacy, and the part I like is the attempt to engineer a logging system
that narrowly meets your requirements while preventing widespread
exploitation of logs for another usage. This is going to be a widespread
problem. Keeping too much data in the log invites abuse, and may be a
violation of privacy regulations. But some data is obviously useful, be
it for debugging purposes, security analysis, or in your example a
desire to provide data for legitimate law enforcement purposes.

There are efforts to achieve something similar with DNS logs, e.g.:
https://datatracker.ietf.org/doc/draft-dickinson-bcp-op/. They end up
using the same bag of tricks, combinations of encryption, hashing and
indexing. This is a difficult engineering problem, with know pitfalls
like de-anonymization. The first part of solving a problem like that is
to understand the requirements, and specifically understand the
envelope, delineate what "narrowly meeting the requirements" would mean.
Your draft is a great contribution to that.

On the other hand, I am far less enthusiastic with proposed solutions
such as using IP addresses as keys. It comes close to another known
issue in the field, "designing your own crypto". I am also not convinced
at all by your section 6.1, cryptographic strength. Contrary to your
assertion, 64 bit keys are not considered strong today, and would be a
mere speed-bump to a determined adversary. How about we first gather the
requirements, and then have some kind of study of the best solutions?

-- Christian Huitema

---

From: Dave O'Reilly <[email-masked]>
Date: Wed, 30 May 2018 21:35:00 +0100

Christian,
> mixes requirements and a very specific solution.

It’s not published with the intention of being a solution to any specific problem. There are several reasons why I published this document:

1. Technical design and societal consequences of the technical design cannot be neatly separated. It is not necessarily the case that societal consequences can be effectively addressed after technology design is finished and a technology has been widely deployed.
2. It is important and appropriate, in my opinion at least, for the IETF to consider the consequences of technical decisions made in this forum on law enforcement. This is the reason why I chose temporary addresses in SLAAC as the basis of my document - it is a good example of a technology that /by design/ eliminates crime attribution evidence and its use will therefore have significant negative impact on law enforcement effectiveness. This is a very different thing to logs not being available - it is a technological design choice.
3. I am trying to make the point that there are solutions to be found that can help to address the challenges being faced by law enforcement without compromising on privacy, if there is a willingness to recognise those challenges, recognise the legitimate needs of law enforcement and to think creatively about the problem(s).

> privacy,

I object to this characterisation of my position. 

Firstly there is no such thing as MY requirements. Secondly I’m not trying to strike a balance between anything and anything - I have stated the reasons why I published this paper in my comment above. 

I do, however, acknowledge that there is a balance to be struck (not by me, but in a broader sense) between individual right to privacy and other rights such as the rights of victims to have an effective criminal justice system to support them. However, privacy appears to trump all other considerations in this forum. 

As I mentioned to someone in a private discussion recently on a related topic, there is a need not only to recognise that such a balance is necessary but also to make sure that (a) the balance between the two is right (for some definition of right) and (b) that to the greatest extent possible - within the balance defined by (a) - the requirements of both are met and (c) that the trajectory of Internet engineering effort is towards maintenance of balance rather than veering towards one extreme or the other.

I am of the opinion that the IETF is zero out of three on these criteria.

> and the part I like is the attempt to engineer a logging system
> exploitation of logs for another usage.

Not MY requirements!!!

> This is going to be a widespread

Thank you. Perhaps an interesting discussion can be had on this point - see some thoughts below. 

> issue in the field, "designing your own crypto”.

I’m not designing any crypto - the paper suggests the use of AES. 

> I am also not convinced
> mere speed-bump to a determined adversary.

I understand that 64 bit keys are not considered strong. Again, you’re missing the point(s) I was trying to make which I have outlined above - this is not a serious proposal for a technical standard of any sort - it is supposed to indicate that there are possibilities available to address challenges in a privacy sensitive way. If, on the other hand, people take the technical proposal seriously, maybe there’s someone out there who can think of a way of expanding the key space. 

> How about we first gather the

I’m not optimistic that this will lead anywhere useful but why not have a try…

Here are some preliminary thoughts on the requirements question:

1. The aim of law enforcement is to enforce the law. What does this mean - amongst other things identification, and investigation, of breaches of criminal legislation (within some jurisdiction). 
2. Investigation of criminal activity must be done with the expectation that the investigation will be scrutinised in a court in due course. 
3. Therefore the findings of the investigation must be supported by appropriately collected and managed evidence (as laid out in the criminal procedure code or equivalent in some jurisdiction).
4. Some or all of this evidence may be technical in nature. 

So, the principle requirement of law enforcement in this context is for admissible evidence that will have some probative value in an investigation. 

There are lots of peripheral issues that could be considered and I’m happy to discuss them if people want, such as:

- the role of judicial oversight in investigations
- international treaties that govern transfer of evidence between jurisdictions
- the rights and wrongs of the laws in different jurisdictions
- definitions of different types of crimes
- different types of law enforcement agencies
- rule of law
- evidence control and chain of custody, as it applies to electronic evidence
- different definitions of the word “evidence” - I have given a general definition here

but generally speaking the point remains that the principle requirement of law enforcement is for admissible evidence that will have some probative value in an investigation. 

What next?

daveor