Re: meeting minutes

[Michael McNeil <[e-mail]>]

Denis Pinkas wrote:
>Michael,
>As you say it, the minutes from the meeting are correct.

>>Stephen Kent wrote:
>>[snip]
>>>NEW TOPICS:
>>>- Timestamp & Notary proposals (Carlisle Adams)
>>>
>>>Several folks continuing work on these topics and have published
>>>an independent draft on these topics. The authors received a fair
>>>amount of private feedback, and hope to be able to bring forward a
>>>well-formed proposal. Jeff Schiller gave his permission to bring
>>>this into the WG, based on the WG having made substantial progress
>>>on the other work items. Thus we will expand the charter to
>>>encompass these topics.

>>This is what occurred during the PKIX sessions at the 42nd IETF
>>meeting with regards to timestamping; however the above is not
>>the whole story.
>>
>>Between sessions at the IETF meeting I talked with various people
>>about the new Internet-Draft (authored by Dave Mills, Todd Glassey,
>>and me) which extends the NTP protocol towards serving as a vehicle
>>for PKI certified and secured time ("ephemeral" time; "what time is
>>it *now*?" time), as well as also providing for *timestamps* of
>>data -- within the same protocol, essentially as gravy (a different
>>usage, I admit).

>From your short description,  people might think that the two drafts
>are equivalent.

Yes, thank you for pointing that out.  The two sets of drafts are quite
distinct, of course, as we're well aware.  I thought insufficiently of
the readers' perspective in wording the description unfortunately.

>Let me highlight some of the main differences:
>Let us call:
>
>"draft 1", the draft:
>ftp://ietf.org/internet-drafts/draft-adams-time-stamp-02.txt

Et al.

>and "draft 2", the draft:
>ftp://ietf.org/internet-drafts/draft-mills-ntp-auth-coexist-01.txt
>
>Draft 1 is all in ASN1, as the rest of the other messages supported
>by PKIX, e.g. CMP. So it is in the spirit of the other documents. On
>the contrary, Draft 2 is supporting 32 bits words and is much more
>compact (unless that advantage will be lost by many extensions !)

We think not, but good point.

>The time formats are different between draft 1 and 2. Draft 1 is
>using the same time format as the rest of the PKIX documents, while
>draft 2 is using a 32 bits time representation.

NTP actually uses 64 bits of time, with 32 bits of fractional second
information.  The 32-bit seconds count will roll over in 2038; I have
suggested (Dave Mills and I disagree as to the desirability of this)
that 8-bit extensions to the time fields be added in an extension field.

>Draft 1 supports the time stamping of an imprint and as a side
>effect, may provide a trusted time when using the optional nonces.

The question is what would be the quality of the time (ephemeral time)
passed using that protocol.  A heavyweight protocol almost by definition
takes more time to convey than a lightweight one -- and it's the quality
of the time itself that we're interested in here (ignoring timestamps
for the moment).  A longer time to pass the time futzes the precision of
the time.  Moreover, draft 1 lacks the fractional seconds information
NTP maintains, lacks the extra fields NTP possesses which allow it to
communicate the accuracy of the time and the last time that the server's
time was updated from a reliable source.  These last deficiencies can be
fixed, of course, in the draft 1 proposal (though perhaps not the
"heavyweight" issue); any deficiencies in the draft 2 protocol noted
below can also be repaired (except perhaps the "lightweight" issue). ;-)

>Draft 2 is unclear about time stamping, in particular the indication
>of the hash function used for the imprint and its protection. It
>allows various extension fields and so the minimum format to be
>supported is left undefined.

Draft 2 is a work in progress (this last is the second version), and
admittedly is less finished in this regard than draft 1.  We expect to
have another Internet-Draft ready for publication, with details of the
important extensions fields fleshed out, by the 43rd IETF in December.

>It is also unclear about the replay protection when only the time
>is returned (unless that information is present is some other
>documents ?).

NTP has inherent replay resistance in that if your time is already
reasonably good, replay attacks are instantly visible as being old. 
Moreover, NTP normally (despite conveying an absolute time) only steers
the time -- it doesn't reset a machine to a radically different time,
appearing out of the blue within an NTP packet.  Even so, additional
authentication is desirable to present spurious NTP attacks; that is the
point of the "draft 2" Internet-Draft.  A more fundamental protection
against replay attacks, from a cryptographic point of view, is to
require that the client as a sanity check do a unicast probe of the
server every now and then, rather than depending on broadcast packets,
including random bits of its own in its request -- which then get echoed
back in the signed NTP reply from the server.  Detecting its bits in the
reply, the client knows it's in response to its own most recent request.

>>I spoke with Jeff Schiller about this.  After he'd had a chance
>>to look over the Internet-Draft (i.e.,
>><draft-mills-ntp-auth-coexist-01.txt>), we spoke again, very near
>>the end of the IETF meeting.  Jeff at that time suggested that
>>since it was now apparent to him that the issue of PKI and time
>>goes well beyond the question of timestamps to the issue of how
>>secure *time itself* can be conveyed over an insecure network, he
>>thought that perhaps the PKIX working group was not equipped to
>>properly address this expanded issue -- or at least Jeff thought
>>the IESG ought to be consulted first on the question before the
>>issue of PKIX handling it or a separate "time" working group
>>being set up is laid to rest.

>From what is above, "draft 2" would not be usable in a PKIX
>environment, where the compactness of the messages is not the
>issue, since the Time Stamp will be used mostly either in a
>store and forward environment or in a local environment.
>
>However, there may be some good reasons to have a 32 bits
>oriented and more compact protocol for acquiring a secure time
>for other environments and therefore it can make sense to have
>two protocols.

I agree.

>>Thus the issue stands as far as I know.  I've addressed two e-mails
>>to Jeff since the IETF meeting (on 8 and 21 September) but so far
>>have not received a reply (I assume it takes time to poll the IESG
>>membership).  I have no particular stake in which way the decision
>>goes (except I think *some* working group needs to address time
>>*and* timestamping),

>I am not sure that a *single* working group needs to address both
>time and timestamping.

Good point.

>As a good example, we have already have the PKIX and the SPKI
>working groups: PKIX is using ASN.1, while SPKI does not.
>A similar parallelism ! :-)

A parallelism I hope doesn't draw a rain of stones and bricks!  ;-)

>>but wished to alert you that despite the outcome of the PKIX sessions,
>>the question of whether PKIX handles it appears not quite settled.

Thank you for your comments, Denis!

Regards,
Michael McNeil
GMT
[e-mail]
1-831-438-7811