Re: [cti] Timestamps, yet again

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Sounds good to me. I vote the same.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Patrick Maroney ---01/19/2016 12:31:23 PM---Precision #1 & Timezone #2 Pat

From: Patrick Maroney <Pmaroney@Specere.org>
To: "Barnum, Sean D." <sbarnum@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>
Cc: Joey Peloquin <joey.peloquin@citrix.com>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 01/19/2016 12:31 PM
Subject: Re: [cti] Timestamps, yet again
Sent by: <cti@lists.oasis-open.org>

---

Precision #1 & Timezone #2

Pat
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Sean Barnum <sbarnum@mitre.org>
Date: Tuesday, January 19, 2016 at 11:24 AM
To: Bret Jordan <bret.jordan@bluecoat.com>, Alexander Foley <alexander.foley@bankofamerica.com>
Cc: Joey Peloquin <joey.peloquin@citrix.com>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Timestamps, yet again

I’d vote for Precision #1 & Timezone #2

sean

From: <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, January 19, 2016 at 11:12 AM
To: "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>
Cc: Joey Peloquin <joey.peloquin@citrix.com>, Eric Burger <Eric.Burger@georgetown.edu>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Timestamps, yet again

For me I would vote for Precision 1 and Timezone 1.   

Having the timezone offset also gives some implicit context of where the event took place in a follow the sun.  This can give some additional context and understanding.


Thanks,

Bret



Bret Jordan CISSP 
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 19, 2016, at 07:39, Foley, Alexander - GIS <alexander.foley@bankofamerica.com> wrote:

For the record, I didn’t care about nanoseconds – that was coming from other members of the community.

Precision 1, Timezone 1 would be my vote

Thanks,

Alex

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Joey Peloquin
Sent: Monday, January 18, 2016 4:51 PM
To: 'Eric Burger'; cti@lists.oasis-open.org
Subject: RE: [cti] Timestamps, yet again

I’d vote for Precision 1, Timezone 2.

At the f2f, I don’t recall anyone other than Alex caring about precision less than a second (nanosecond).

Joey
--
Joey Peloquin, Senior Manager
Citrix Security | Threat Intelligence and Vulnerability Management
Citrix Systems, Inc. | 851 West Cypress Creek Road | Fort Lauderdale, FL 33309
m (817) 412-0475 | o (954) 229-5649 | e joey.peloquin@citrix.com

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Eric Burger
Sent: Monday, January 18, 2016 3:11 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] Timestamps, yet again

My preference is Precision 1 Timezone 2, or +1 to John’s proposal.

The only real issue is if the precision is less than a second, e.g., 1/10th minutes (6 seconds), 1/4 minutes (15 seconds), or even whole minutes. The question then is does anyone care?


On Jan 18, 2016, at 2:46 PM, Wunder, John A. <jwunder@MITRE.ORG> wrote:

How about we put together concrete proposals for precision and for timezone?

Precision proposals:
• (1): Separate precision field, values are: year, month, day, hour, minute, second (default = second). Any precision below the second is implicit in the number of fractional seconds in the timestamp field.
• (2): Separate precision field, values are: year, month, day, hour, minute, second, decisecond, centisecond, millisecond, microsecond, nanosecond (default = microsecond).
Timezone proposals:
• (1): Timezone is required, may be any valid offset
• (2): Timezone is required, MUST be UTC (Z)
Do these cover the various proposals? I intentionally didn’t include proposals with not much support (ISO-8601 for precision, not requiring timezone). My read of the f2f was that we didn’t discuss anything relevant for the precision proposals but for timezone #2 is in line with the consensus.

If we’re going to vote, my vote is Precision 1 and Timezone 2. In all honesty though at this point I think any of the proposals are workable.

John

From: <cti@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Monday, January 18, 2016 at 2:28 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Timestamps, yet again

Summary:
Time Zones specified with a Z and in UTC only.
Arbitrary fractional second precision.
One note at the end about time stamp precision.

Time Zone Coding

Time Zone Thing #1:
Anything that cannot be unambiguously translated into UTC never, ever gets put on the wire. I.e., you can choose between T and an offset or Z. Once we agree on Thing #1, then we are looking at what our preference would be.

Time Zone Thing #2:
We are expecting global usage, or at least usage spanning time zones. As such, no matter how one stores data, i.e, everything in UTC or everything in local time + UTC offset, the client will be doing time zone calculation to translate into local time for display or analysis.

Time Zone Thing #3:
Given thing #2, from a global efficiency perspective, we might as well only allow UTC. The client sending the original message will need to know its local time zone anyway to properly format the offset. As such, it might as well do the calculation to send the time in UTC. That way the server needs no calculations of time zone offset. The retrieving clients are all likely to be doing time zone calculations no matter what time zone the server sends the time in, so there is no extra burden here. In fact, if the client is an analysis bot, it will want things in UTC anyway.

Proposal:
Mandate UTC (Z) time.
If you want to employ Postel’s Law, feel free to accept offset (T) time. However, that will encourage bad behavior and should be discouraged. Senders MUST NOT send anything other than Zulu time.


Precision Coding

Precision Thing #1:
Parsers have to scan the entire time stamp to ensure we are not getting snared by fuzzing, buffer overflowing, insane values, etc. At that point, it does not matter whether we have fixed-length time stamps or variable-length time stamps.

Precision Thing #2:
Various applications have various needs. For some, 15-second precision is more than adequate, like for physical security analysis applications. For others, sub-nanosecond precision is barely adequate, like for 10GE traffic flow analysis.

Precision Thing #3:
Because today we are talking about applications needing between zero and nine digits of precision, and with 1TbE a future possibility, it makes neither sense to mandate a default precision nor precision indicators. Recall Precision Thing #1 above. Your parser will be scanning the entire time stamp string no matter what. You might as well read until you find the delimiting space.

Precision Thing #4:
Both RFC 3339 and ISO 8601 specify arbitrary fractional second precision. Nothing new here.

Precision Thing #5:
If you really believe scanning the time stamp to read the fractional number of seconds is computationally a time suck, sponsor a tiny bit of work and we’ll do an open source implementation that will blow doors off you bad implementations ;-)

Proposal:
No specified limits or markings for fractional seconds.


Issue about Precision
Does anyone care about the measured precision being transmitted along with the data? For example, is 12:34:56.000000 really saying that, to the microsecond, it was 12:34:56, or is it just saying that to the nearest second that was the time? Conversely, does 12:35:00 mean precisely at 12:35, about 12:35, or somewhere between 12:34:30 and 12:35:29? Again, do we care?

On Jan 18, 2016, at 11:42 AM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

Eric Berger has very strong opinions about this, and should be back online next Monday. Lets make sure we give him time to comment. But, for everyone else, please speak up. We really need to put this to bed soon.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 18, 2016, at 09:26, Struse, Richard <Richard.Struse@HQ.DHS.GOV> wrote:

There is nothing to prevent us from restricting the use of RFC 3339 datetime’s to UTC. We CAN do it and I believe the consensus at the F2F was that we should.

From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Monday, January 18, 2016 11:21 AM
To: Struse, Richard
Cc: cti@lists.oasis-open.org
Subject: Re: Timestamps, yet again

So requiring the timestamps to be in UTC is divergent from RFC 3339. RFC 3339 requires that times be derived off of UTC, which is what I think we all want. Meaning you can NOT do this:

2016-01-18T11:10:10 and expect people to think that it is EDT. That would and should FAIL. You would need to do:

2016-01-18T11:10:10-04:00 for EDT or you could do 2016-01-18T15:10:10Z / 2016-01-18T15:10:10+00:00

I think if we are going to go down the path of RFC 3339, regardless of my previous comments, we should just use it as is. This will hopefully guarantee that libraries will work.

So I would say:

The "timestamp" field in STIX, CybOX, and TAXII MUST use an RFC 3339 compliant timestamp that includes a timezone offset from UTC or the value is in UTC with a "Z". Examples:

2016-01-18T11:10:10-04:00
2016-01-18T11:10:10.123456-04:00

This means you can include as many or as few fractional sections as you want.

The "timestamp_precision" field will be at the same level as the "timestamp" field and will be optional. The default precision is Microseconds. This field in JSON is a string field and has the following valid options in the ENUM:

Year
Month
Day
Hour
Minute
Second
Millisecond
Microsecond
Nanosecond


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 18, 2016, at 09:05, Struse, Richard <Richard.Struse@HQ.DHS.GOV> wrote:

The more I thought about this the more my thinking was driven by what various datetime libraries allow the developer to do. While in a perfect world I’d prefer the ISO 8601 “just specify what you know” (which allows 2016-01-01 for example to say January 1, 2016), libraries that support 8601 don’t seem to give the developer any way of distinguishing between “2016-01-01” and “2016-01-01T00:00:00.0Z”. Therefore, we’re better off going with RFC 3339 which mandates a full date/time and the separate precision specifier we’ve previously discussed. As far as fractional seconds, I say we allow zero or more digits – the libraries support that, it’s compliant with RFC 3339 and at the F2F no one could articulate a reason why that was a burden to implementers.

So, in summary:
RFC 3339
All times expressed in UTC (“Z”)
Separate precision specifier

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, January 18, 2016 10:58 AM
To: cti@lists.oasis-open.org
Subject: [cti] Re: Timestamps, yet again

Thoughts??? We really need to decide this. This along with IDs are the next major things we need to resolve and resolve SOON.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 14, 2016, at 22:19, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

As this issue was brought up at the Face2Face, and thus reopened for debate and consensus, and the consensus today was leaning toward the use of RFC3339 as is, without further stipulation and the removal of timestamp_precision field, I thought it would be best to re-read the RFC for clarification.

Section 4.2. Local Offsets
Allows for local time, so long as it is an offset from UTC

5.8. Examples
1996-12-19T16:39:57-08:00


I do not see anything in RFC3339 that allows for dates/times with less precision than a fully qualified timestamp: yyyymmddThh:mm:ssZ

ISO8601 does explicitly allow for reduced precision by just truncating the value.


From my understanding of the community we have the following requirements:
1) Represent reduced precision
2015Z
201501Z
20150114Z
20150114T23Z
20150114T23:21Z
20150114T23:21:20Z
20150114T23:21:20.1Z
20150114T23:21:20.12Z
20150114T23:21:20.123Z
etc.
2) Represent an arbitrary number of fractional sections
20150114T23:21:20.1Z
20150114T23:21:20.12Z
20150114T23:21:20.123Z
etc.
3) Represent values in local time as a offset to UTC or in UTC
20150114T23:21:20.123456Z
20150114T23:21:20.123456-08:00



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."



---

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.