Hi Mohamed,

I dont agree with this bit:

> Adjusting the log records to synchronize with a global time source is the 
> responsibility of the entity which owns the server. 

I think that both in principle and in practice this synchronisation/correction 
would be carried out by law enforcement as part of their investigation. There 
might, I suppose, be an expectation that a server operator would indicate if 
there was a difference between the times in their logs and a standard time 
reference but in any case the law enforcement officer is going to have to go 
through the logs and calibrate the times in the context of whatever matter they 
are investigating.

The log data plus analysis/calibration would form part of the justification for 
issuing a subpoena for CGN records (depending on jurisdiction), and the law 
enforcement officer would have to be able to stand over the grounds for 
accessing the logs if the request is challenged. If the information being 
requested is heavily dependent on the accuracy of the times stated in the 
request, as might be the case if CGN was in use, one could reasonably expect to 
be asked to justify that the times indicated are accurate (with reference to 
some sort of time standard) - at which point the law enforcement officer, 
forensic analyst, or whoever gathered the evidence would need to be able to 
explain how they concluded that the times in the subpoena were the correct 
ones. This would presumably include any offset calibration that was carried 
out, or at least the results of an investigation to confirm that such a 
calibration was not required.

Also, if a server operator adjusted the times in logs before providing them as 
evidence, it is not beyond the realm of possibility that the 
authenticity/integrity of the evidence could be challenged because the log data 
has been altered since it was recorded.

Regards,
daveor

> On 6 Apr 2018, at 08:03, <mohamed.boucad...@orange.com> 
> <mohamed.boucad...@orange.com> wrote:
> 
> Hi Dave, 
> 
> Glad to see that we are in agreement. 
> 
> I don't think that those sections are needed for the reasons explained in my 
> previous message.  
> 
> One way to avoid misinterpreting your draft as conflicting with existing RFCs 
> is to tweak section 7.4, e.g.:
> 
> OLD:
> 
>   There are many reasons why it is may not be possible to record logs
>   with reference to a centralised time source (e.g.  NTP).  This could
>   include scenarios should as security sensitive networks, or internal
>   production networks.  Times MAY OPTIONALLY be recorded with reference
>   to a centralised time source (e.g.  NTP) but this is not necessary.
>   As long as times are recorded consistently, it should be possible to
>   measure the offset from a reference time source if required for the
>   purposes of quering records at another source.  This is common
>   practice in digital forensics.
> 
> NEW:
> 
>   There are many reasons why it may not be possible for servers to record logs
>   with reference to a global time source.  This could
>   include scenarios such as security sensitive networks, or internal
>   production networks. As long as times are recorded consistently, it should 
> be possible to
>   measure the offset from a traceable global time source (if required) for the
>   purposes of querying records at another source. Adjusting the log records 
> to 
>   synchronize with a global time source is the responsibility of the entity
>   which owns the server. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Dave O'Reilly [mailto:r...@daveor.com]
>> Envoyé : jeudi 5 avril 2018 16:29
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : int-area@ietf.org
>> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
>> 
>> Hi Mohamed,
>> 
>> Thanks for your mail.
>> 
>> I agree with you.
>> 
>> The only reason I put these sections in here was because the IESG conflict
>> review indicated a conflict between this document and the other two RFCs
>> mentioned (Ref: https://datatracker.ietf.org/doc/conflict-review-daveor-cgn-
>> logging/). In an effort to reconcile the feedback received with the content
>> of draft-daveor-cgn-logging, I added these sections.
>> 
>> Perfectly happy to remove them if that is the way the consensus emerges.
>> 
>> daveor
>> 
>> 
>>> On 5 Apr 2018, at 15:24, <mohamed.boucad...@orange.com>
>> <mohamed.boucad...@orange.com> wrote:
>>> 
>>> Hi Dave,
>>> 
>>> I have a comment about the proposed update to RFC 6269 (the same comment
>> applies for RFC6302, though).
>>> 
>>> Actually, the proposed NEW text will require an extra effort to align
>> timestamps among the server which maintains the logs, the authorities that
>> relay an abuse claim, and the provider who manages the CGN. That extra effort
>> has to be done by the entity managing the log server.
>>> 
>>> From that standpoint, the proposed NEW text is no more than another example
>> of "Accurate time-keeping"...which IMHO does not justify an update to the
>> 6269.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Dave
>> O'Reilly
>>>> Envoyé : mercredi 4 avril 2018 22:26
>>>> À : int-area@ietf.org
>>>> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
>>>> 
>>>> Dear all,
>>>> 
>>>> Further to my email below, I have revised draft-daveor-cgn-logging and
>>>> revision -03 is now available. I have restructured the content into the
>> form
>>>> of recommendations.
>>>> 
>>>> Here’s the link: https://tools.ietf.org/html/draft-daveor-cgn-logging-03
>>>> 
>>>> I have also included, at sections 7.6 and 7.7, proposed amendments to
>> RFC6302
>>>> and RFC6269 respectively.
>>>> 
>>>> Regards,
>>>> daveor
>>>> 
>>>>> On 20 Mar 2018, at 13:45, Dave O'Reilly <r...@daveor.com> wrote:
>>>>> 
>>>>> Dear all,
>>>>> 
>>>>> further to presenting at IETF-101 yesterday I wanted to send a follow up
>>>> email to see if there is interest in working on a new best current
>> practice
>>>> for logging at internet-facing servers.
>>>>> 
>>>>> I hope I adequately presented the reasons why I think there needs to be
>>>> some revision of the recommendations of RFC6302 and that there is some
>>>> additional points to be considered in draft-daveor-cgn-logging-02.
>>>>> 
>>>>> The current version of the document (draft-daveor-cgn-logging-02)
>> contains
>>>> recommendations, but it is not really in the form of a BCP. If there is
>>>> interest, I would like to suggest, in the first instance at least, that I
>>>> prepare a new version of the document, structured in the form of a BCP
>> with a
>>>> set of recommendations for discussion.
>>>>> 
>>>>> Any feedback would be appreciated.
>>>>> 
>>>>> Thanks and best regards,
>>>>> daveor
>>>>> 
>>>>> _______________________________________________
>>>>> Int-area mailing list
>>>>> Int-area@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/int-area
>>>> 
>>>> _______________________________________________
>>>> Int-area mailing list
>>>> Int-area@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/int-area
> 

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to