Christian, > > I like the general tone of your draft, but I am a bit concerned that it > 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). > You are trying to strike a balance between your requirements and > 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 > that narrowly meets your requirements while preventing widespread > exploitation of logs for another usage. Not MY requirements!!! > 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. > Thank you. Perhaps an interesting discussion can be had on this point - see some thoughts below. > 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’m not designing any crypto - the paper suggests the use of AES. > 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. 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 > requirements, and then have some kind of study of the best solutions? > 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
