Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302

Dave O'Reilly <rfc@daveor.com> Sat, 07 April 2018 14:31 UTC

Return-Path: <rfc@daveor.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126A71270AB for <int-area@ietfa.amsl.com>; Sat, 7 Apr 2018 07:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zChGapFRkS2l for <int-area@ietfa.amsl.com>; Sat, 7 Apr 2018 07:31:01 -0700 (PDT)
Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61B812708C for <int-area@ietf.org>; Sat, 7 Apr 2018 07:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=MectuKbvTQHBYFjM7zV2OYf3mUr0jwuXOoWUXaFP0vA=; b=eN2AkPsLLnaieOS7DO9UKulcCf Xc6zTe9lYpT4JQvKYE04sYW3+yrLMUhBioOamj5PByfGuYZMs9ffcIN5XTiz80nJcs3G2Ru07vk5n gUH0+Im77+bJRtMrI/9WR6FHOYG+iTKh9GTbtaEZ44VgXjtkLs/G7RGrJqHNoEi9cMm8=;
Received: from 86-44-56-31-dynamic.agg7.bsn.cld-dbn.eircom.net ([86.44.56.31]:62798 helo=[192.168.1.26]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89_1) (envelope-from <rfc@daveor.com>) id 1f4orq-0001tI-I6; Sat, 07 Apr 2018 15:30:58 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave O'Reilly <rfc@daveor.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF9184@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Sat, 07 Apr 2018 15:30:57 +0100
Cc: "int-area@ietf.org" <int-area@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <76F47DAB-E160-4FE9-82FE-E1F6C6264BD6@daveor.com>
References: <CE7E9C19-E906-48A8-B2DF-C86C48C1D95D@daveor.com> <8E6F0C13-486F-47A9-B1F6-255D915AEE69@daveor.com> <787AE7BB302AE849A7480A190F8B93302DEF8B55@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <4A0A5ACC-9754-419E-8AA2-43C74A0C08D4@daveor.com> <787AE7BB302AE849A7480A190F8B93302DEF9184@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3124)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - daveor.com
X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com
X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/3VhQAhihkd0YVqk1byR_ZNQVbcg>
Subject: Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Apr 2018 14:31:04 -0000

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.boucadair@orange.com> <mohamed.boucadair@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:rfc@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.boucadair@orange.com>
>> <mohamed.boucadair@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-bounces@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 <rfc@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
>