Re: nping echo protocol rfc, feedback

["Luis MartinGarcia." <luis.mgarc () gmail com>]

Hi Toni,

Again, sorry for the late reply. I've reconsidered some of your
suggestions:


On 03/11/2011 03:59 PM, Toni Ruottu wrote:
> There could be multiple simultaneous connections in which case the
> "the previous NEP_HANDSHAKE_CLIENT message" might have arrived over
> another connection. Changing this to "the preceding
> NEP_HANDSHAKE_CLIENT message" would clarify the situation, if I
> understood the meaning correctly.

Ok, the text now reads "the preceding" message.


> > > In the same chapter the explanation of Error Message field explains
> > > requirements for null characters. I think it would make sense to
> > > clarify that the last byte of the field needs to be null in all cases.
> >
> > I don't agree with this one. I thinks that can be trivially inferred
> > from the description.
>
> It can be inferred, but it is also a fact that always holds. And
> stating facts that always hold is useful. Any other part of the
> explanation only affects the end result, while having the last byte
> always be null, is a safety measure. Of course an implementation
> should not rely on the last byte being null.
>
> I am worried that someone might store an error message which is
> exactly 640bits, thinking that the terminator is not required when the
> whole field is used. Alternatively you could clarify the maximum
> length of the message. "The null terminator always takes one byte,
> leaving 632bits for the string payload."

I still think that there is no way to interpret the text wrong. It says:

  Contains a NULL-terminated ASCII string that describes the reason
  why the session is being terminated by the sender. The string MUST
  contain a NULL character (0x00) at the end of it. The remaining
  bytes, if any, must also be set to zero.

It states twice that the string has a NULL byte at the end, and there
is a big MUST there so I'm sorry but I prefer no to change the current
wording.




> > > In the key explanations sometimes the concatenation is marked as
> > > (SERVER_NONCE|CLIENT_NONCE) and sometimes not. I tried really hard to
> > > figure out if the two cases were different, but I am still not sure. I
> > > think they are the same. Maybe the notation should be copied to all
> > > cases or dropped.
> >
> > You are right. I've replaced the "|" symbol with the plus sign to make
> > all concatenations consistent.
>
> That was not the problem. I'll clarify
>
> For NEP_KEY_MAC_C2S it is said that "NONCES equals the server nonce in
> the NEP_HANDSHAKE_SERVER message, concatenated with the client nonce
> in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE)"
>
> For NEP_KEY_CIPHERTEXT_C2S it is said that "NONCES equals the server
> nonce in the NEP_HANDSHAKE_SERVER message, concatenated with the
> client nonce in the NEP_HANDSHAKE_CLIENT message."
>
> Why is the later one lacking the equation? Some of the descriptions
> have the equation and some do not have it. Is there a difference?
> Should all of them have the equation?


At first I did not understand what you were trying to say but now I do
so I've added the equation to the description of all keys.

I've just updated the RFC. Thanks again for taking the time to review
the RFC.

Regards,

Luis MartinGarcia.






_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/