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

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

On 5/29/2018 5:59 AM, Dave O'Reilly wrote:
> Hi Alex,
>
> Thanks for your feedback.
>
>
>> On 29 May 2018, at 13:13, Alexandre Petrescu <alexandre.petrescu@gmail.com> 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.
>
>> 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.
>>
>>
> 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
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area