Subject: Re: [Trans] "current NTP time"

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Aug 2018 12:31:22 +0100

I just started to prepare a PR for this, but...

RFC6962 says:
    "timestamp" is the current NTP Time [RFC5905], measured since the
    epoch (January 1, 1970, 00:00), ignoring leap seconds, in
    milliseconds.

6962-bis currently says:
    "timestamp" is the current NTP Time [RFC5905], measured in
    milliseconds since the epoch (January 1, 1970, 00:00 UTC), ignoring
    leap seconds.

RFC5905 section 6 says:
   "In the date and timestamp formats, the prime epoch, or base date of
    era 0, is 0 h 1 January 1900 UTC, when all bits are zero."

1970 != 1900, and (IINM) NTP time does not ignore leap seconds.

ISTM that what we're actually using is Unix time 
(https://en.wikipedia.org/wiki/Unix_time), and so we should say that 
we're using Unix time.  It makes no sense to claim to be using NTP time 
if we're not actually doing that.

Two possible ways forward:

1. Replace the "NTP time" references with "Unix time", and find a 
suitable reference (any ideas?) to point to.

2. Switch to actually using the 64-bit NTP timestamp format.  This might 
confuse implementers that are already familiar with RFC6962 though.

Any preferences?  (I favour option 1).

On 28/07/18 23:37, Melinda Shore wrote:
> On 7/28/18 7:02 AM, Benjamin Kaduk wrote:
>> Thanks for pulling up the primary source; I was just going on the chairs'
>> summary of the issues and apparently only noticed an unrelated potential issue.
>> Clarifying that the 64-bit timestamp format (with callout to Sectino 6 of
>> RFC 5905) is the correct one sounds like a fine thing to do.
> 
> D'oh!  But in fairness the what was under discussion was in
> response to the meeting minutes, which do accurately capture
> the discussion in Montreal.  I'll bug the authors.
> 
> Melinda

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [email-masked]

---

From: Jon Callas <[email-masked]>
Date: Wed, 15 Aug 2018 10:08:16 -0700

> On Aug 15, 2018, at 4:31 AM, Rob Stradling <[email-masked]> wrote:
> 
> ISTM that what we're actually using is Unix time (https://en.wikipedia.org/wiki/Unix_time), and so we should say that we're using Unix time.  It makes no sense to claim to be using NTP time if we're not actually doing that.
> 
> 1. Replace the "NTP time" references with "Unix time", and find a suitable reference (any ideas?) to point to.
> 
> 2. Switch to actually using the 64-bit NTP timestamp format.  This might confuse implementers that are already familiar with RFC6962 though.
> 

Thank you for this. I think it’s important to define it to Unix time or equivalent rather than NTP. At best, NTP is going to refer it to Unix time or equivalent, and you’d have the problem of people debating what to do if they use some other protocol than NTP.

I think that if you say, “64-bit, unsigned Unix time” it’s pretty well-defined. You could even explain once that it’s the number of seconds since 1 January 1970 UTC and then it’s defined about as completely as possible.

	Jon

---

From: Aanchal Malhotra <[email-masked]>
Date: Wed, 15 Aug 2018 13:25:22 -0400

Hi All,

I am not a 100% sure what is exactly required here. So FWIW,

1) If it is a question about the encoding and wire format of the NTP
timestamp (NTP synchronize to the UTC timescale), then I would suggest
looking at the working draft
https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-02#page-6

2) If it is about the type of time and date format to be used, the closest
reference would be RFC 3339. https://tools.ietf.org/html/rfc3339

3) If the idea is just to refrain from mentioning "NTP" at all, then I
would agree with what Jon said  to go with "64-bit, unsigned Unix time”
should be good enough.

Best,
Aanchal.

On Wed, Aug 15, 2018 at 1:08 PM, Jon Callas <
joncallas=[email-masked]> wrote:

> > ISTM that what we're actually using is Unix time (
> https://en.wikipedia.org/wiki/Unix_time), and so we should say that we're
> using Unix time.  It makes no sense to claim to be using NTP time if we're
> not actually doing that.
> >
> Thank you for this. I think it’s important to define it to Unix time or
> equivalent rather than NTP. At best, NTP is going to refer it to Unix time
> or equivalent, and you’d have the problem of people debating what to do if
> they use some other protocol than NTP.
>
> I think that if you say, “64-bit, unsigned Unix time” it’s pretty
> well-defined. You could even explain once that it’s the number of seconds
> since 1 January 1970 UTC and then it’s defined about as completely as
> possible.
>
>         Jon
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Aug 2018 14:34:01 +0100

> > 1970 != 1900, and (IINM) NTP time does not ignore leap seconds.

NTP's specification is amazingly opaque on this matter, but there is a
fixed offset between NTP time and POSIX time of (365*70 + 17) * 86400 ==
2,208,988,800 which is the "First day UNIX" value in the table in RFC 5905
section 6. You can see from the "Last day 20th Century" that NTP and Unix
apply leap seconds to their timestamps in the same way (i.e. they don't).

$ perl -MPOSIX -e 'print strftime "%F.%T\n", gmtime (3155587200 - 2208988800)'
1999-12-31.00:00:00

> well-defined. You could even explain once that it’s the number of
> seconds since 1 January 1970 UTC and then it’s defined about as
> completely as possible.

It isn't just the number of seconds since 1970-01-01 :-)

RFC 4034 summarizes it as:

   The Signature Expiration and Inception field values specify a date
   and time in the form of a 32-bit unsigned number of seconds elapsed
   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
   byte order.

POSIX time is defined in The Open Group Base Specifications Issue 7 /
IEEE Std 1003.1-2008, 2016 Edition, volume 1 (XBD) section 4.16 "Seconds
Since the Epoch"

http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay: Northerly or northwesterly 4 or 5. Slight becoming moderate.
Rain for a time. Good, occasionally moderate.

---

From: Eran Messeri <[email-masked]>
Date: Fri, 24 Aug 2018 11:28:58 +0100

I've proposed text to the effect of clarifying that we're using Unix time
at:
https://github.com/google/certificate-transparency-rfcs/pull/299