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