[ntpwg] [Gen-art] Review: draft-ietf-ntp-autokey-05.txt

[David Mills]

Folks,

I was too hasty in my complaint about PDF; I see the RFCs are in PDF; 
however, they are in Courier monospace font and I can't read them even 
after magnification. None of my workspace documetns are formatted in 
this way; they use easy to read proportional font like Times Roman. The 
really irritating thing is the requirement for text-set graphics when 
all kinds of other eye-friendly graphics programs and formats are available.

In spite of the fact I can almost read RFCs in PDF, the markup and 
formatting problems are acute. There must be a better way than to start 
with ASCII text.

Dave

David Mills wrote:

> Brian,
>
> A markup as per Joel's request is at 
> www.eecis.udel.edu/~mills/draft-ietf-ntp-autokey-06.xml. 
> Unfortunately, the xml2rfc utility complains that the draft NTPv4 
> document referenced does no exist, so I can't test it. My suite of 
> modern spell checkers do not work with xml documents and my trusty old 
> eye-friendly spell checkers do not work with modern video cards.
>
> If there is something you can do at your end so xml2rfc works, I would 
> be glad to llight up the text and at least make sure the markup 
> doesn't break syntax. As for the spell checker, I am toast.
>
> However, I no longer can easily  read RFCs or IDs in text due 
> diminished eyesigtht. I have to import documents in wordpad, force the 
> font to bold and then  magnify until I can see them. This works  with 
> word-wrapped text like xml, but not with line-break text like RFCs and 
> IDs, where the irregular brokenl lines become too hard proofread in 
> long documents.
>
> Now, I say this in the company of the IETF representatives here. My 
> opposition to RFC text format in favor of PDF has been fierce, angry 
> and ineffective for over twenty years. With PDF dim-eyed folks like me 
> can fly, and that is how I do my personal work. Everything I need is 
> available in PDF, including journal articles, symposium papers, IEEE 
> standards, patents, NASA archives, even archives of my old reports at 
> various Universities.
>
> The IETF insistence on archaic and for me unworkable document format 
> is unfriendly, unecessary, possibly unethical and just plain wrong.
>
> Dave
>
> Brian Haberman wrote:
>
>> Joel,
>>      Thanks for the review.  At this point, I will not have time to 
>> look at these comments until later this week or possibly early next 
>> week.  When I do, I will provide responses to your comments.
>>
>> Thanks,
>> Brian
>>
>> Joel M. Halpern wrote:
>>
>>> I have been selected as the General Area Review Team (Gen-ART)
>>> reviewer for this draft (for background on Gen-ART, please see
>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>>
>>> Document: draft-ietf-ntp-autokey-05.txt
>>>     Network Time Protocol Version 4 Autokey Specification
>>> Reviewer: Joel M. Halpern
>>> Review Date: 5-June-2009
>>> IETF LC End Date: 12-June-2009
>>> IESG Telechat date: N/A
>>>
>>> Summary: While nearly ready for publication as an Informational RFC, 
>>> this document has some issues that need to be addressed before 
>>> publication.  The issues are described by priority below.
>>>
>>> Major issues:
>>>     There appears to be some confusion in the protocol description 
>>> as to which field actually tells you what message you are handling, 
>>> and which field tells you that this is NTP Autokey.  In teh text in 
>>> section 10, it says that the "Field Type" field is set to 2, and 
>>> represents a version number.  Further, it says that the 6-bit Code 
>>> field specifies the request or response.  Unfortunately, all of the 
>>> subsections of section 10 carefully and consistently refer to having 
>>> different "Field Type" values, not different Code values.
>>>     Section 4 of this document is explicit that MD5 is the 
>>> (singular) hash algorithm for generating message signatures and 
>>> autokeys.  I was concerned about lack of algorithm agility.  Section 
>>> 11.1 however includes a 16 bit Digest / Signature NID.
>>> 1) There is no description of how this is used / negotiated
>>> 2) There is no explanation of the relationship between this and the 
>>> earlier assertion of MD5
>>> 3) While the text mentions that this is defined in "the OpenSSL 
>>> library", there is no reference, and particularly no reference to 
>>> any documentation to see what values are defined.  Since this ought 
>>> to be implementable by someone who does not live in the OpenSSH 
>>> world, a reference is necessary.
>>> 4) There is no mention of what happens if the value proposed by the 
>>> host and the values supported by the server do not match.
>>>
>>> Moderate issue:
>>>
>>>     The IETF does not normally use "reference implementations." 
>>> Therefore, it would be helpful if early in this document there were 
>>> text describing what the reference implementation is, how it is 
>>> found, and what the relationship of that reference implementation to 
>>> this RFC is.
>>>
>>>     I believe that the wording on hierarchy in section 5, paragraph 
>>> 3 is exactly the opposite of what is shown in the figure.  (And what 
>>> is shown in the figure matches what I would expect.)  The text says:
>>>    Secure groups can be configured as hierarchies where a TH of one
>>>    group can be a client of one or more other groups operating at a
>>>    lower stratum.
>>> But in fact, what I think happens is that a client of one group 
>>> operates as the TH of a group operating at a lower stratum.
>>>
>>>     Section 10, the paragraph that begins "[T]he extension field 
>>> parser initializes a pointer..." has some sort of problem.  After 
>>> reading this several times, I am pretty sure that "the length" by 
>>> which the pointer is increment is the length in the extension 
>>> header, not the length computed by subtracting the NTP header from 
>>> the packet length.  If so, please insert test (probably after the 
>>> "greater than 20" check and before the "not multiple of 4 check") 
>>> that describes something like "The extension header is found 
>>> immediately after the NTP header.  The length of the extension 
>>> header is checked to ensure that this length plus the 20 bytes for 
>>> the MAC header does not exceed the calculated remaining octets of 
>>> the packet."
>>>
>>> Minor issues:
>>>
>>>     In figure 5, it would probably help the reader if the groups and 
>>> hosts were not named identically.  (Even just calling the groups 
>>> Alice-Group and Carol-Group would help.)
>>>
>>>    In section 5, in the description of "[t]he steps in hiking the 
>>> certificate trails...", in step 1, in the second sentence, could you 
>>> please add language to make it clear that what the server is 
>>> "exchanging host names and negotiating..." with is the server from 
>>> whom it is getting information.  It took rereading the list to 
>>> realize that this was not about the servers initiating communication 
>>> with the clients who use them.  (Yes, I know that such initiation is 
>>> impossible.  Which is why an extra couple of words would help.)  
>>> Part of this is because common terminology, and later usage in this 
>>> document, is that the machine in this role (the "server" who is 
>>> starting to exchange host names ...) is called the client, if I have 
>>> parsed the protocol correctly.
>>>
>>>     Is there any way section 8 could be moved earlier in the 
>>> document?  One of the problems reading the document is that various 
>>> parts early in the document assume properties of the system which 
>>> have not been described yet.
>>>
>>>     I am not sure if this is an issue that should be described in 
>>> the security considerations section, or whether I am missing 
>>> something that helps.  There are multiple references to the need for 
>>> Identity mechanisms.  But those mechanisms are not part of this 
>>> draft.  If I read things properly, if identity verification is not 
>>> used then a man-in-the-middle can step into the stream, and assuming 
>>> he can convince clients (possibly by packet misdirection) to talk to 
>>> him, he can produce an apparently valid certificate chain and simply 
>>> lie about the time. (Yes, there is mention earlier of other aspects 
>>> of NTP that moderate his potential impact.  But if we did not care 
>>> about this, then this document would not exist.)
>>>
>>> Nits/editorial comments:
>>>     It appears that section 11.6 (Security Considerations) is 
>>> supposed to be a top-level sections, with 11.7 and 11.8 as 
>>> sub-sections of that.
>>>
>>>
>>>
>>>
>>
>
>