Subject: [ntpwg] Pending NTP WG Last Call on Autokey

From: Brian Haberman <[email-masked]>
Date: Fri, 02 May 2008 09:36:12 -0400

All,
         The Autokey draft is now available via the I-D repository. 
Unless someone objects, we will start a WG Last Call the week of May 5th.

Regards,
Brian

-------- Original Message --------
Subject: I-D ACTION:draft-ietf-ntp-autokey-02.txt
Date: Tue, 22 Apr 2008 12:15:01 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Time Protocol Working Group of
the IETF.

	Title		: Network Time Protocol Version 4 Autokey Specification
	Author(s)	: B. Haberman, D. Mills
	Filename	: draft-ietf-ntp-autokey-02.txt
	Pages		: 52
	Date		: 2008-4-22
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Danny Mayer <[email-masked]>
Date: Fri, 02 May 2008 11:29:27 -0400

> Unless someone objects, we will start a WG Last Call the week of May 5th.

We cannot start last call since we have not completed last call on the 
NTPv4 draft.

I also have major objections to section 10 of this document since it 
appears to use the Field Type to carry protocol-private data instead of 
placing that information in the body of the extension. There is also 
mention of a code field but there is no description or figure for it and 
where it is resident in the extension. I already raised this as an issue 
  to the working group and except for a short discussion with Dave Mills 
I  have not heard anyone else respond to this. We need to do this.

We need to sort this out before we move this forward.

Danny

---

From: "Greg Dowd" <[email-masked]>
Date: Fri, 2 May 2008 08:33:28 -0700

I raised the same issue against the last draft.  I know Dave rewrote
that section but I haven't looked at the new version.  I'll try to catch
up.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com
"Everything should be made as simple as possible, but no simpler" Albert
Einstein

> -----Original Message-----
> From: ntpwg-bounces+gdowd=[email-masked] 
> [mailto:ntpwg-bounces+gdowd=[email-masked]] On 
> Behalf Of Danny Mayer
> Sent: Friday, May 02, 2008 8:29 AM
> To: Brian Haberman
> Cc: NTP Working Group
> Subject: Re: [ntpwg] Pending NTP WG Last Call on Autokey
> 
> Brian Haberman wrote:
> > All,
> I also have major objections to section 10 of this document 
> since it appears to use the Field Type to carry 
> protocol-private data instead of placing that information in 
> the body of the extension. There is also mention of a code 
> field but there is no description or figure for it and where 
> it is resident in the extension. I already raised this as an issue
>   to the working group and except for a short discussion with 
> Dave Mills I  have not heard anyone else respond to this. We 
> need to do this.
> 
> > This draft is a work item of the Network Time Protocol 
> Working Group 
> > of the IETF.
> >

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 02 May 2008 16:38:08 +0000

Danny,

I hear no proposals about extension fields other than my last proposed 
rewrite of that section. There really is no wiggle room other than 
deprecating Autokey in its present form and reformatting the headers. I 
am not opposed to that in principle, but others, specificlly USNO, have 
not been heard from.

Dave

---

From: Danny Mayer <[email-masked]>
Date: Sat, 03 May 2008 18:56:42 -0400

Dave,

My proposal that I sent out quite a long time ago was to steal a bit 
from the length field and set it to 1 for the updated protocol so that 
the particulars of the autokey protocol remains private inside the 
header extension itself and keeps it outside the field type. That way 
the servers (including those of NIST, USNO, etc.) can continue to work 
with both versions (the old and the new). The old clients (servers) will 
continue to work. Taking away one bit from the length field reduces the 
maximum extension length from 65535 to 32767 which I don't think we will 
ever need or can use.

It's this lack of privacy of this data that causes interoperability 
problems between Autokey and Microsoft's MS-SNTP protocols, otherwise 
this issue would never have arisen.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 04 May 2008 16:41:13 +0000

Dannt,

Each of us has proposed stealing bits from the length field or the code 
fields. I find stealing from the length field inelegant, while you might 
find theft of code bits crude. Your proposal cleaves Autokey from any 
other and does not necessarily provide for multiple others. I prefer my 
proposal.

Dave

Danny Mayer wrote:

> with both versions (the old and the new). The old clients (servers) 
> will continue to work. Taking away one bit from the length field 
> reduces the maximum extension length from 65535 to 32767 which I don't 
> think we will ever need or can use.
>
>
>> I hear no proposals about extension fields other than my last 
>> proposed rewrite of that section. There really is no wiggle room 
>> other than deprecating Autokey in its present form and reformatting 
>> the headers. I am not opposed to that in principle, but others, 
>> specificlly USNO, have not been heard from.
>>
>>
>> Dave
>>

---

From: Danny Mayer <[email-masked]>
Date: Sun, 04 May 2008 22:08:31 -0400

Dave,

You misunderstand me. I'm proposing that autokey complies as well. 
conformance bit set to 1 indicates that you are conforming to the 
protocol while conformance bit 0 (which it would have to be in order to 
be the top bit of the length field) would mean the old format and would 
be non-compliant with the autokey protocol and the NTPv4 spec. The old 
autokey usage of the field type would go away.

I'll send you the layout at little layer.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 05 May 2008 14:22:31 +0000

Danny,

No sell. There are numeous examples of prior art in the use of a 16-bit 
length field in IP and UDP. I do not think it clean at all to poach on 
the length field. In any case, it doesn't really make much difference. 
What you see is what you get unless you have a specific proposal for a 
competitive protocol. Right now I don't hear anything.

Dave

Danny Mayer wrote:

> protocol while conformance bit 0 (which it would have to be in order 
> to be the top bit of the length field) would mean the old format and 
> would be non-compliant with the autokey protocol and the NTPv4 spec. 
> The old autokey usage of the field type would go away.
>
>
>> Each of us has proposed stealing bits from the length field or the 
>> code fields. I find stealing from the length field inelegant, while 
>> you might find theft of code bits crude. Your proposal cleaves 
>> Autokey from any other and does not necessarily provide for multiple 
>> others. I prefer my proposal.
>>
>>
>> Dave
>>
>>
>> Danny Mayer wrote:
>>
>>
>>> Dave,
>>>
>>>
>>> from the length field and set it to 1 for the updated protocol so 
>>> that the particulars of the autokey protocol remains private inside 
>>> the header extension itself and keeps it outside the field type. 
>>> That way the servers (including those of NIST, USNO, etc.) can 
>>> continue to work with both versions (the old and the new). The old 
>>> clients (servers) will continue to work. Taking away one bit from 
>>> the length field reduces the maximum extension length from 65535 to 
>>> 32767 which I don't think we will ever need or can use.
>>>
>>>
>>> problems between Autokey and Microsoft's MS-SNTP protocols, 
>>> otherwise this issue would never have arisen.
>>>
>>>
>>> Danny
>>>
>>>
>>> David L. Mills wrote:
>>>
>>>
>>>> Danny,
>>>>
>>>>

---

From: Danny Mayer <[email-masked]>
Date: Mon, 05 May 2008 21:37:54 -0400

Dave,

I'm not buying it. I don't give a hoot about prior art. I'm trying to 
fix the original problem of your overloading the type field with private 
  codes. This is a workaround to allow the old usage to continue to work 
while the code is upgraded to the correct usage and to allow 
interoperation between the old and the new. The old will be obsoleted 
after several releases.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 06 May 2008 03:51:31 +0000

Danny,

We are having a violent disagreement. The disagreement will continue 
with enthusiasm. Stay out of the length field. Leave things as they are 
and get this damn puppy out the door. When a new appliation surfaces for 
the extension fields, consider a revised format and junk the existing 
format.

Dave

Danny Mayer wrote:

> fix the original problem of your overloading the type field with 
> private  codes. This is a workaround to allow the old usage to 
> continue to work while the code is upgraded to the correct usage and 
> to allow interoperation between the old and the new. The old will be 
> obsoleted after several releases.
>
> Danny
> David L. Mills wrote:
>
>> Danny,
>>
>> No sell. There are numeous examples of prior art in the use of a 
>> 16-bit length field in IP and UDP. I do not think it clean at all to 
>> poach on the length field. In any case, it doesn't really make much 
>> difference. What you see is what you get unless you have a specific 
>> proposal for a competitive protocol. Right now I don't hear anything.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>> Dave,
>>>
>>>
>>>> Autokey from any other and does not necessarily provide for 
>>>> multiple others. I prefer my proposal.
>>>>
>>>>
>>>> Dave
>>>>
>>>>
>>>> Danny Mayer wrote:
>>>>
>>>>
>>>>> Dave,
>>>>>
>>>>>
>>>>> My proposal that I sent out quite a long time ago was to steal a 
>>>>> bit from the length field and set it to 1 for the updated protocol 
>>>>> so that the particulars of the autokey protocol remains private 
>>>>> inside the header extension itself and keeps it outside the field 
>>>>> type. That way the servers (including those of NIST, USNO, etc.) 
>>>>> can continue to work with both versions (the old and the new). The 
>>>>> old clients (servers) will continue to work. Taking away one bit 
>>>>> from the length field reduces the maximum extension length from 
>>>>> 65535 to 32767 which I don't think we will ever need or can use.
>>>>>
>>>>>
>>>>> It's this lack of privacy of this data that causes 
>>>>> interoperability problems between Autokey and Microsoft's MS-SNTP 
>>>>> protocols, otherwise this issue would never have arisen.
>>>>>
>>>>>
>>>>> Danny
>>>>>
>>>>>
>>>>> David L. Mills wrote:
>>>>>
>>>>>
>>>>>> Danny,
>>>>>>
>>>>>>
>>>>>> other than deprecating Autokey in its present form and 
>>>>>> reformatting the headers. I am not opposed to that in principle, 
>>>>>> but others, specificlly USNO, have not been heard from.
>>>>>>
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>

---

From: Danny Mayer <[email-masked]>
Date: Sat, 10 May 2008 19:03:57 -0400

Dave,

Absolutely not. We need to do this now before there are too many 
implementations in the field. Do it now and get it over with.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 11 May 2008 03:33:56 +0000

Danny,

Don't fool with the length field. This goes cross puposes with other 
protocols such as IP and UDP. We are not going to see hundreds or even 
dozens of extension field types in NTP. What you suggest creates a 
ghetto for Autokey and does not provide a framework for 
type/version/opcode encoding. No proposal is complete without that 
encoding. The solution I proposed is completely adequate for whatever 
purpose extension fields might be used for; the implied generality is 
not worth the obscurity and incompatible model it creates.

Dave

Danny Mayer wrote:

>> with enthusiasm. Stay out of the length field. Leave things as they 
>> are and get this damn puppy out the door. When a new appliation 
>> surfaces for the extension fields, consider a revised format and junk 
>> the existing format.
>>
>> Dave
>>
>> Danny Mayer wrote:
>>
>>> Dave,
>>>
>>> I'm not buying it. I don't give a hoot about prior art. I'm trying 
>>> to fix the original problem of your overloading the type field with 
>>>> 16-bit length field in IP and UDP. I do not think it clean at all 
>>>> to poach on the length field. In any case, it doesn't really make 
>>>> much difference. What you see is what you get unless you have a 
>>>> specific proposal for a competitive protocol. Right now I don't 
>>>> hear anything.
>>>>
>>>> Dave
>>>>
>>>> Danny Mayer wrote:
>>>>
>>>>> Dave,
>>>>>
>>>>>
>>>>> protocol while conformance bit 0 (which it would have to be in 
>>>>> order to be the top bit of the length field) would mean the old 
>>>>> format and would be non-compliant with the autokey protocol and 
>>>>> the NTPv4 spec. The old autokey usage of the field type would go 
>>>>> away.
>>>>>
>>>>>
>>>>>> Each of us has proposed stealing bits from the length field or 
>>>>>> the code fields. I find stealing from the length field inelegant, 
>>>>>> while you might find theft of code bits crude. Your proposal 
>>>>>> cleaves Autokey from any other and does not necessarily provide 
>>>>>> for multiple others. I prefer my proposal.
>>>>>>
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>> Danny Mayer wrote:
>>>>>>
>>>>>>
>>>>>>> Dave,
>>>>>>>
>>>>>>>
>>>>>>> bit from the length field and set it to 1 for the updated 
>>>>>>> protocol so that the particulars of the autokey protocol remains 
>>>>>>> private inside the header extension itself and keeps it outside 
>>>>>>> the field type. That way the servers (including those of NIST, 
>>>>>>> USNO, etc.) can continue to work with both versions (the old and 
>>>>>>> the new). The old clients (servers) will continue to work. 
>>>>>>> Taking away one bit from the length field reduces the maximum 
>>>>>>> extension length from 65535 to 32767 which I don't think we will 
>>>>>>> ever need or can use.
>>>>>>>
>>>>>>>
>>>>>>> interoperability problems between Autokey and Microsoft's 
>>>>>>> MS-SNTP protocols, otherwise this issue would never have arisen.
>>>>>>>
>>>>>>>
>>>>>>> Danny
>>>>>>>
>>>>>>>
>>>>>>> David L. Mills wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Danny,
>>>>>>>>
>>>>>>>>
>>>>>>>> proposed rewrite of that section. There really is no wiggle 
>>>>>>>> room other than deprecating Autokey in its present form and 
>>>>>>>> reformatting the headers. I am not opposed to that in 
>>>>>>>> principle, but others, specificlly USNO, have not been heard from.
>>>>>>>>
>>>>>>>>
>>>>>>>> Dave
>>>>>>>>
>>>>>>>>

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 11 May 2008 06:18:17 -0700

AutoKEY is not the only auth mechanism that NTP should support - I am in 
favor of a more open interface model of which AutoKEY is one of several auth 
mechanism's put in place, but AutoKEY is broken by design - it doesn't scale 
and has a limited number of possible cached keys such that 
broad-distribution models with this NTP is not possible.

On the other hand there is OpenNTP as well - and NIST's NTP which both don't 
follow this track either.

Dave - I respect you immensely but this isnt about you or your NTP anymore - 
its one of the key problems with people's like Danny's abusive commentary 
too. It shows how little the physicists in this WG understand evidence 
models or what testimonial's are like.

The reality is that this NTP is broken... and it isnt getting any better 
IMHO - just more difficult to fix.

Todd Glassey

---

From: Rob Seaman <[email-masked]>
Date: Sun, 11 May 2008 08:12:58 -0700

I'm concerned to see this bout of sniping - however, sniping was  
certainly one of the internet's earliest protocols.  (One might,  
however, tender the observation that some people have expertise in  
both physics and computer science - and in systems engineering and  
human factors, for that matter.)

Stripping away the ad hominem layer (as adding no signal to the  
discussion):

TS Glassey wrote:

> AutoKEY is not the only auth mechanism that NTP should support

Returning to the beginning of this thread:

David L. Mills wrote:

>>>>>>>>>> There really is no wiggle room other than deprecating  
>>>>>>>>>> Autokey in its present form and reformatting the headers. I  
>>>>>>>>>> am not opposed to that in principle, but others,  

Where is the disagreement?  There is a world of difference in any  
standards discussion, of course, between what should happen and what  
will happen.  The answer always lies in what needs to happen.

One is confident that a single workable consensus - not compromise -  
remains possible.

> broad-distribution models with this NTP is not possible.

Clarification, please, on what is meant by a "broad-distribution  
model"?  How, in detail, does broad-distribution differ from other  
kinds of distribution?  That is - describe the problem before  
suggesting a solution.

Does this thing called broad-distribution fall within the purview of  
NTP in any event?  And is the world really clamoring for it?  Does our  
world's social and technical infrastructure *need* "broad- 
distribution", or does this simply reside in the Hilbert space of what  
*should* be?

Rob Seaman
National Optical Astronomy Observatory
--
"Maybe all one can do is hope to end up with the right regrets."  -  
Arthur Miller
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 11 May 2008 08:29:53 -0700

Rob - the Court Ruling from the US District Court in Lorraine V Markel (by 
Judge Paul W. Grimm on May 4th 2007) set the standard for what digital 
content and first-person v third-person type testimony models. This is now 
something that the world is going to address - and it changes what the world 
needs from timekeeping systems IMHO. What they need now is good or better 
resolution - and absolute reliability in the veracity of the logging 
therein. Without that - timesetting's are based on the credibility of the 
person making that setting IMHO.

Todd Glassey

---

From: Danny Mayer <[email-masked]>
Date: Sun, 11 May 2008 14:25:24 -0400

Dave,

The problem that I'm trying to work around is that you put private 
autokey data in a public place. That limits the usability of the 
extension type field. The type/version/opcode encoding should reside 
within the extension and not outside. This is what is creating the 
ghetto not what I am suggesting. Doing whatever you want in a particular 
field requires that you keep it private to the protocol rather than 
public as you have done.

It makes any future extensions difficult if not impossible and that's 
what needs to be addressed.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 11 May 2008 14:45:37 -0400

> One is confident that a single workable consensus - not compromise -  

That is my reason for suggesting that we take a bit out of the header so 
that the current autokey implementation continues to work while enable 
the correct layout to be implemented in parallel. This is pretty 
straightforward stuff and allows us to move ahead.

> distribution", or does this simply reside in the Hilbert space of what  

I have no clue what is meant by broad-distribution models and I have yet 
to see anywhere in the protocol where it's even mentioned, never mind 
required. Since there is no request to add that as a requirement, nor 
language to insert, I see no reason for discussing it further.

I have seen claims that that Autokey does not scale without any 
empirical evidence of this (and physicists love to see real data on 
this) nor is there any evidence that it is broken by design. There is 
nothing in the draft that requires scalability. We have been presented 
with no proof of how to decide whether or not it is broken or in what 
way. If the protocol design is flawed then we need that information 
presented before it can be fixed.

I discount legal opinions that do not even address these issues as they 
are not protocol requirements nor is the protocol the only way of 
addressing a legal issue.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 12 May 2008 03:23:30 +0000

Danny,

I strongly disagree. If you want it private, define a type in my 
proposal that says the following is private.

Dave

Danny Mayer wrote:

> ghetto not what I am suggesting. Doing whatever you want in a 
> particular field requires that you keep it private to the protocol 
> rather than public as you have done.
>
>> protocols such as IP and UDP. We are not going to see hundreds or 
>> even dozens of extension field types in NTP. What you suggest creates 
>> a ghetto for Autokey and does not provide a framework for

---

From: "David L. Mills" <[email-masked]>
Date: Mon, 12 May 2008 03:48:42 +0000

Todd,

I'd really like to understand your points. What are "first-person v 
third-person type testimony models"? The court expressed the need for 
improved resolution. The resolution of the PTP and NTP representation is 
today better than the time light travels one foot. There must be 
something else here.

The more interesting point is "absolute reliability in the veracity of 
the logging therin". We computer science and engineering types interpret 
that as impossible to do. We can provide massive redundancy and 
diversity and clever mitigation algorithms at sometimes considerable 
cost. The computer science community has tossed this issue around for 
many years. We cannot provide "absolute reliability". Surely, competent 
counsel and consultants should have made that point. Go talk to the 
patent lawyers; they are engineers.

Now, where is the lesson here for the NTP community? You have predicted 
dire consequences and meltdown. Be more specific. What is broken and 
what is to fixed? We need an engineering colloquy, not a legal brief.
 
Dave

Dave

---

From: Rob Seaman <[email-masked]>
Date: Sun, 11 May 2008 22:49:23 -0700

TS Glassey wrote:

> the Court Ruling from the US District Court in Lorraine V Markel (by  
> Judge Paul W. Grimm on May 4th 2007) set the standard for what  
> digital content and first-person v third-person type testimony models.

Thanks for the interesting reference.  Is this online somewhere?  I'll  
simply echo Dave's questions.

Rob Seaman
NOAO

---

From: Rob Seaman <[email-masked]>
Date: Sun, 11 May 2008 23:44:35 -0700

Danny Mayer wrote:

> I have no clue what is meant by broad-distribution models and I have  
> yet to see anywhere in the protocol where it's even mentioned, never  
> mind required.

Todd didn't answer any of my (pretty rhetorical) questions, but made  
it clear that his third of this discussion centers on specifying legal  
requirements.  Dave (quite understandably) appears to want to simply  
put this puppy to bed.  I doubt I'm alone in finding this an  
attractive option.  Your "third way" position is:

> That is my reason for suggesting that we take a bit out of the  
> header so that the current autokey implementation continues to work  
> while enable the correct layout to be implemented in parallel.

My reaction to this is from http://www.dspcsp.com/tictoc:

>> The NTP Working Group is currently standardizing the fourth version  
>> of NTP for time distribution over IP networks. The NTP WG has  
>> focused its deliverables largely on standardizing the currently  
>> deployed NTPv4, while collecting requirements for future  
>> extensions. These requirements will transition to the TICTOC WG for  
>> further development.

Why now, rather than later?  Wouldn't a staged deployment be prudent?   
Or perhaps there is something here I'm missing?  If so, I also doubt  
I'm alone in this.

Rob

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 12 May 2008 07:22:42 -0700

----- Original Message ----- 
From: "Rob Seaman" <[email-masked]>
To: "NTP Working Group" <[email-masked]>
Sent: Sunday, May 11, 2008 11:44 PM
Subject: Re: [ntpwg] Pending NTP WG Last Call on Autokey

> Todd didn't answer any of my (pretty rhetorical) questions,

Danny if in the middle of your slamming my ideas and concerns there was an 
Idea I was supposed to respond to it wasnt apparent. The issues are VERY 
clear and very specific.

> but made
> put this puppy to bed.

You mean to release yet another instance of an NTP that is 'the same as it 
used to be' - I understand the need to keep it status quo - that's why 
people like the OpenNTP team have their release and this WG has its.

> I doubt I'm alone in finding this an
> attractive option.

You mean because a number of the WG's people are not interested in building 
a system that is particularly implemented because of the strength of the 
evidence model it creates? I totally understand - we are talking about what 
people to to earn a living - making this an issue of... Oh my - people's 
putting their personal and professional financial status above the needs of 
the world regarding NTP?

> Your "third way" position is:
>
> Or perhaps there is something here I'm missing?

Because if any more work was done on a 'proper' distribution, one which 
meets the commercial auditing needs for timekeeping in IT frameworks, much 
of the work done over the past couple of years may need to be redone - based 
on the "Digital Evidence needs" controlling this effort.

> If so, I also doubt  I'm alone in this.
>
> Rob
>
>
>

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 12 May 2008 07:38:54 -0700

Yep - and I am working with the GAO to integrate these requirement's into
the brand-new version of FISCAM which the GAO is running out for comment's
to the CIO's offices of the various Federal Agencies.

This is a good listing from LEXIS-NEXIS, and I can send you a copy of the 
ruling if you want to see it itself.
http://www.lexisnexis.com/applieddiscovery/LawLibrary/whitePapers/ADI_WP_LorraineVMarkel.pdf

A broad Google search produces a wealth of info there. But what people need 
to realize here is that there is a key value in a strong NTP as a core 
evidence source in IT systems. And that is what needs particular focus here 
IMHO.

Todd

http://www.google.com/search?q=Lorraine+v+Markel&rls=com.microsoft:en-us:IE-SearchBox&ie=UTF-8&oe=UTF-8&sourceid=ie7&rlz=1I7GGLF

---

From: Rob Seaman <[email-masked]>
Date: Mon, 12 May 2008 07:47:18 -0700

> This is a good listing from LEXIS-NEXIS,

Yes, saw that.

> and I can send you a copy of the ruling if you want to see it itself.

Yes, please.

> A broad Google search produces a wealth of info there.

Yes, looks like an important (legal) decision.

> But what people need to realize here is that there is a key value in  
> a strong NTP as a core evidence source in IT systems. And that is  
> what needs particular focus here IMHO.

I doubt the folks here need a judge to tell them that timekeeping is  
important to many aspects of social as well as technical  
infrastructure :-)

The questions are how and when.

Rob

---

From: Rob Seaman <[email-masked]>
Date: Mon, 12 May 2008 08:00:55 -0700

I'm only replying further because my words and Danny's are getting  
interchanged.

TS Glassey wrote:

> The issues are VERY clear and very specific.

A legal opinion can only function to inform use cases and  
requirements, not systems developed from those requirements.  Which is  
to say that it may or may not be very clear and specific what the  
implications are for defining the problem, but nothing has been said  
or will be said by any jurist about defining any engineering solution  
responsive to those requirements.

I, for one, don't find that the legal requirements have been clearly  
stated as yet.

The commentaries I've seen focus on some legal process distinction  
between the discovery of evidence and its admission at trial.   
Similarly, requirements must be discovered before they are addressed  
by a system engineering process.

Additional unhelpful ad hominem (a very legal notion) statements  
deleted.  In particular, there are no engineers getting rich off  
this :-)

> much of the work done over the past couple of years may need to be  
> redone - based on the "Digital Evidence needs" controlling this  
> effort.

All software systems are best regarded as (functional, if you're  
lucky) prototypes.  The question is whether a particular solution is  
satisfactory for some purpose, for some period of time.  Focus on that  
question, not on whether NTP is optimum.  No system is optimum for all  
purposes.

One might be naturally skeptical of doing work for free for a legal  
system that will only repay that effort in the future with unending  
subpoenas :-)  If the U.S. government wants a legally mandated  
timekeeping system, they should fund same.

Rob

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 12 May 2008 08:15:56 -0700

----- Original Message ----- 
From: "Rob Seaman" <[email-masked]>
To: "NTP Working Group" <[email-masked]>
Sent: Monday, May 12, 2008 8:00 AM
Subject: Re: [ntpwg] Pending NTP WG Last Call on Autokey

> responsive to those requirements.

Actually in Judge Grimm's ruling he admonished "Counsel to get it right the 
first time" meaning that the people the counsel are relying on also need to 
get it right the first time or the evidence then enter may be dismissed with 
predjudice.

> I, for one, don't find that the legal requirements have been clearly

They are indeed very clearly stated. No one has said to you personally 'This 
is specifically what you need to do to meet those hurdles' who you would 
believe. And this is the same "excuse" the rest of the world tried to scate 
by.

> satisfactory for some purpose, for some period of time.

Apparently that solution is not any more...

> Focus on that
> subpoenas :-)

Ahahahah - yep.

>If the U.S. government wants a legally mandated

One would think -

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 May 2008 05:03:13 -0400

Dave,

You can ignore the legal case referenced. I read the decision in its 
entirety (all 101 pages) and while it does reference timestamps and 
dates and times it does not have any specific requirements for time. 
Indeed for most purposes outlined in the decision the timestamp on a 
document residing on a computer could easily be 5 minutes off and still 
be acceptable, hardly an NTP issue.

The need for accuracy in the timestamp depends almost entirely on the 
nature of what the attorney is trying to prove. You and I both know that 
there are 100 different ways from Sunday to provide false timestamps on 
any document on the system without detection. Witness this odd quote in 
the decision: "it is common for the proponent to provide evidence of the 
input procedures and their accuracy, and evidence that the computer was 
regularly tested for programming errors." Noone is testing their 
computers in this way for the applications that they are running except 
for the people developing the applications. When was the last time that 
you tested Microsoft Word?

You can read the actual decision if you can stomach the dry legalese 
here: http://indianalawblog.com/documents/Lorraine_v_Markel.pdf
The discussion is mostly about the Federal Rules of Evidence and 
admissibility.

Now can we get back to the working group issues?

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 May 2008 05:04:31 -0400

> simply echo Dave's questions.

The correct reference is: 
http://indianalawblog.com/documents/Lorraine_v_Markel.pdf

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 May 2008 05:10:53 -0400

> attractive option.  Your "third way" position is:

Right. This draft is not a legal requirements document, it's a technical 
protocol document.

> My reaction to this is from http://www.dspcsp.com/tictoc:

TICTOC has a different agenda.

> Or perhaps there is something here I'm missing?  If so, I also doubt  

I want to get this out too. The trouble is that I want to do this right 
rather than do it over much later when it's much harder to recover. Dave 
is rarely wrong about NTP but we are talking about interoperability and 
extensibility and crippling the protocol at the beginning limits its 
usefulness.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 May 2008 05:51:38 -0400

> important to many aspects of social as well as technical  

The judge didn't say that either. The judge only discusses what is 
needed to make evidence stored or sourced on a computer or other 
electronic devices admissible as evidence and how they are to introduce 
it and with what ancillary proofs and witnesses. There is no discussion 
of what would happen if the computer was off by 5 minutes or an hour or 
three days.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 May 2008 06:09:34 -0400

This is the way it should look according to my new scheme:

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Extension Identifier        |1|          Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|   Code    |Reserved | VN  |   Reserved - MUST be 0        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For old autokey configurations it would look like this:

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|E|   Code    |Reserved | VN  |0|          Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notice that bit 16 would be 0 anyway since the length is not currently 
that large.

Now we have privitized the autokey private information but still allow 
it to interoperate with the updated protocol.

Danny
David L. Mills wrote:
> Bian,
> 
> Oops, you found errors, both in the diagram and text describing the Code 
> field. The first word should be
> 
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |R|E|   Code    |Reserved | VN  |            Length             |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> the text should be
> 
> <t>The 6-bit Code field specifies the request or response operation, 
> while the 3-bit Version Number (VN) field is 2 for the current protocol 
> version. There are two flag bits: bit 0 is the Response Flag (R) and bit 
> 1 is the Error Flag (E); the Reserved field is unused and should be set 
> to 0. The remaining fields will be described later.</t>
> 
> To reprise, the intent of my proposal is to use the Reserved field as a 
> type or class code, with autokey assigned class 0. If other than 0, the 
> bits other than the Reserved bits are arbitrary, but it is my hope that 
> they be interpreted in the same fashion in the interest of code reuse.
> 
> Dave
> 
> Brian Utterback wrote:
> 
>> I hate to enter the fray at this late date, but I only just got a 
>> chance to look at the autokey draft, and I am confused. During the 
>> course of this conversation, there was mention of taking a bit from 
>> the code field or the length field. In the draft it mentions that the 
>> code field is 8-bits and specifies the operation. But I cannot find 
>> either the code or the version field in the format diagram. Where is 
>> the code and version fields located?
>>
>> Brian Utterback
> 
> 
> hackers mailing list
> [email-masked]
> https://lists.ntp.org/mailman/listinfo/hackers
>

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 16 May 2008 17:04:18 +0000

Danny,

In absolutely no way whatsoever does my proposal cripple the protocol 
than does yours gloriously enhance future happiness. My proposal 
preserves current programming style as I designed it, evil as you might 
find it. Yours is as I consider uneccesary, wasteful of header space, at 
odds with current programming style and makes it most difficult to reuse 
code. I'm not going to convince you and you are not going to convince 
me. There you have it. You are invited to purify future versions of this 
or another protocol, but leave this one  alone. Get this puppy out the 
door and save your energy for another time.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 16 May 2008 17:10:50 +0000

Danny,

Your proposal would break the parsing rules that determine if an 
extension field or MAC is present. It also wastes precious header space.

Dave

Danny Mayer wrote:

>> Oops, you found errors, both in the diagram and text describing the 
>> Code field. The first word should be
>>
>>
>> while the 3-bit Version Number (VN) field is 2 for the current 
>> protocol version. There are two flag bits: bit 0 is the Response Flag 
>> (R) and bit 1 is the Error Flag (E); the Reserved field is unused and 
>> should be set to 0. The remaining fields will be described later.</t>
>>
>>
>> To reprise, the intent of my proposal is to use the Reserved field as 
>> a type or class code, with autokey assigned class 0. If other than 0, 
>> the bits other than the Reserved bits are arbitrary, but it is my 
>> hope that they be interpreted in the same fashion in the interest of 
>> code reuse.
>>
>>
>> Dave
>>
>>
>> Brian Utterback wrote:
>>
>>
>>> the code field or the length field. In the draft it mentions that 
>>> the code field is 8-bits and specifies the operation. But I cannot 
>>> find either the code or the version field in the format diagram. 
>>> Where is the code and version fields located?
>>>
>>>
>>> Brian Utterback
>>>
>>

---

From: "TS Glassey" <[email-masked]>
Date: Sat, 17 May 2008 10:16:16 -0700

Danny - sometimes you crack me up.

----- Original Message ----- 

>> important to many aspects of social as well as technical  infrastructure 
>> :-)
>>

Actually we had exactly that convo with Judge Facciola at RSA2008 in San 
Francisco a couple of weeks ago. We plan to have a similar one at RSA2008 
London in October too if they let us.

>
> The judge didn't say that either.

Not true - the case is a matter where the policy terminated prior to a 
lightning strike that would have been covered under the poilicy. So how is 
time not specific to it?

>The judge only discusses what is needed to make evidence stored or sourced 
>on a computer or other electronic devices admissible as evidence and how 
>they are to introduce it and with what ancillary proofs and witnesses.

You crack me up - this isnt for just Judges its for Jury's too. Anyone who 
doesnt plan a good-evidence model with proofs which can be explained and 
proved to 'the average person on the street'  is gambling with IP that may 
cost them everything. Whether you like it or not or even believe it, the 
reality is that culture is being flattened and many of the processes which 
used to provide multiple-first person attestations - ones which were used to 
support assertions' of Integrity have been collapsed into mechanical or more 
autonomic processes, and as such the processes we implement are not as 
reliable from an attestation standpoint that they used to be. Scary thought 
that - add more liers to a process and it gets more reliable - but hey it is 
what it is.

My biggest problem is that this group isnt focused on evidence or the 
creation of it or in coming up with Industry Standards for how NTP 
transactions should work. This group has refused to produce a standard for 
the performance of NTP which is why there is now OpenNTP and other 
implementations.

> There is no discussion of what would happen if the computer was off by 5 
> minutes or an hour or three days.

Sure there is - the evidence would be disqualified. But hey dont believe 
me - lets get your corporate Counsel's opinion on this.

How about this - we allow your client's to voice their comments too on what 
they were led to believe that these systems produce as evidence.  No? I 
didnt think you would want to do that but hey if you change your mind then 
lets rock and roll!

---

From: Danny Mayer <[email-masked]>
Date: Sun, 18 May 2008 14:08:02 -0400

> Danny - sometimes you crack me up.

The laughs on you since it's readily apparent from this message that you 
know nothing about the rules of evidence in the US nor that you actually 
read the decision.

> lightning strike that would have been covered under the poilicy. So how 
> is time not specific to it?

You don't need a timestamp for the policy since the policy has a date 
range of the coverage and that's not even the question being discussed 
in the decision.

>> The judge only discusses what is needed to make evidence stored or 
>> sourced on a computer or other electronic devices admissible as 
>> evidence and how they are to introduce it and with what ancillary 
>> proofs and witnesses.
> 
> You crack me up - this isnt for just Judges its for Jury's too.

You have no idea. In this case the judge clearly stated that it's up to 
the judge to decide on the admissibility of evidence. That has always 
been true but the judge decided to include that statement in his 
decision. The judge is always the one to decide on the admissibility of 
evidence, it is never up to the jury. The jury only gets to decide the 
weight of the evidence as it applies to either side.

> transactions should work.

Your biggest problem is confusing the working group with a legal 
standards and auditing group. It has never been in IETF's charter. Go 
read it.

> This group has refused to produce a standard 
> for the performance of NTP which is why there is now OpenNTP and other 
> implementations.

Performance standards have never been an issue for a protocol group. 
This group is about defining an on-wire standard for interoperability of 
cooperating NTP servers. This group is implementation agnostic. The more 
the merrier.

>> There is no discussion of what would happen if the computer was off by 
>> 5 minutes or an hour or three days.
> 
> Sure there is - the evidence would be disqualified.

No, the importance of the timestamp is dependent on the nature of the 
evidence that is being attempted to be introduced.

> How about this - we allow your client's to voice their comments too on 
> what they were led to believe that these systems produce as evidence.

We make no statement on the usability of the software as evidence of 
anything.

Now lets get back to the business of the working group.

Danny