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

From: Dave O'Reilly <[email-masked]>
Date: Wed, 4 Apr 2018 21:25:55 +0100

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: <[email-masked]>
Date: Thu, 5 Apr 2018 14:24:33 +0000

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:[email-masked]] De la part de Dave O'Reilly
> Envoyé : mercredi 4 avril 2018 22:26
> À : [email-masked]
> 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.
> 
> > 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.
> >

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 5 Apr 2018 15:29:28 +0100

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, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Dave, 
>

---

From: <[email-masked]>
Date: Fri, 6 Apr 2018 07:03:23 +0000

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

> De : Dave O'Reilly [mailto:[email-masked]]
> Envoyé : jeudi 5 avril 2018 16:29
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> 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.
> 
> > 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
> >
> >> I have also included, at sections 7.6 and 7.7, proposed amendments to
> RFC6302
> >> and RFC6269 respectively.
> >>
> >> Regards,
> >> daveor
> >>

---

From: Dave O'Reilly <[email-masked]>
Date: Sat, 7 Apr 2018 15:30:57 +0100

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, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Dave, 
>

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 06:26:49 +0000

Hi Dave, 

What about: 

"The entity which owns the server should indicate the required offset to synchronize with a global time source."

Cheers,
Med

> Envoyé : samedi 7 avril 2018 16:31
> > 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
>

---

From: Dave O'Reilly <[email-masked]>
Date: Mon, 9 Apr 2018 13:42:38 +0100

The only problem that I have with this is the use of the word “should” - I hope I’m not splitting hairs here, but I think there is a slight risk of "victim blaming". 

Consider the scenario where the entity with the Internet-facing server (and therefore with the logs) is a victim of some sort of crime. They have the required logs but they weren’t aware that there was a time offset with reference to a global time source. Again, this is something that happens all the time. Interpreted in this context, I think an indication of what they should have been doing might be a bit on the strong side. What do you think? 

What about this weaker-worded alternative:

“If the entity controlling the server is aware that there is an offset required to synchronise with a global time source, it is expected that the offset would be indicated by the entity while the logs were being collected.” 

daveor

> On 9 Apr 2018, at 07:26, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Dave, 
> 
> What about: 
>

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 13:56:01 +0000

Hi Dave, 

The proposed text would work. 

Cheers,
Med

> Envoyé : lundi 9 avril 2018 14:43
> The only problem that I have with this is the use of the word “should” - I
> hope I’m not splitting hairs here, but I think there is a slight risk of
> "victim blaming".
> 
> Consider the scenario where the entity with the Internet-facing server (and
> therefore with the logs) is a victim of some sort of crime. They have the
> required logs but they weren’t aware that there was a time offset with
> reference to a global time source. Again, this is something that happens all
> the time. Interpreted in this context, I think an indication of what they
> should have been doing might be a bit on the strong side. What do you think?
> 
> “If the entity controlling the server is aware that there is an offset
> required to synchronise with a global time source, it is expected that the
> offset would be indicated by the entity while the logs were being collected.”
> 
> daveor
> 
> 
> >>>  purposes of querying records at another source. Adjusting the log
> records
> >> to
> >>>>> I have a comment about the proposed update to RFC 6269 (the same
> comment
> >>>> applies for RFC6302, though).
> >>>>>
> >>>>>> revision -03 is now available. I have restructured the content into
> the
> >>>> form
> >>>>>> of recommendations.
> >>>>>>
> >>>>>> interest, I would like to suggest, in the first instance at least,
> that
> >> I

---

From: Dave O'Reilly <[email-masked]>
Date: Thu, 12 Apr 2018 17:32:08 +0100

I have uploaded a new version (-04) with the following amendments:

1. Removed proposal to amend RFC6302 and RFC6269.
2. Changed section 7.4 as per our discussion below.
3. Added an acknowledgements section at the end of the document.

See https://datatracker.ietf.org/doc/draft-daveor-cgn-logging/

Regards,
daveor

> On 9 Apr 2018, at 14:56, [email-masked] wrote:
> 
> Hi Dave, 
>