Last Call Review of draft-ietf-syslog-sign-
review-ietf-syslog-sign-secdir-lc-tsou-2009-09-18-00

I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


  These comments were written primarily for the benefit of the security 


area directors.  Document editors and WG chairs should treat these 


comments just like any other last call comments.

In general, from the 
security point of view, this draft does not specify what 

the loghost should 
do in case of packet loss, DoS attack, etc. Should the 

device try to 
retrieve the sys log information again? 

 

Section 1, third paragraph 
(talking about Certificate Block): not to 

over-complicate matters, but this 
is really talking about the content of a 

Payload Block. Rather than 
introduce that term, perhaps rephrase the paragraph 

slightly to make clear 
that multiple Certificate Blocks may be used. What's the key management 
information here? Is it Certificate information or public key information?




 




    Additionally, a signer sends Certificate Blocks to 
provide key

    management information between the signer and 
the collector.  A

    Certificate Block has a field to 
denote the type of key material

    which may be such things 
as a PKIX certificate, an OpenPGP

    certificate, or even an 
indication that a key had been pre-

    distributed.  In 
the cases of certificates being sent, the

    certificates may 
have to be split across multiple Certificate

    Blocks 
carried in separate messages.




 




Section 1, fifth paragraph, first sentence: not clear what "previous" 
refers to. 

The phrase "of the previous messages" doesn't seem to add 
anything and can be 

dropped. Suggest adding "syslog" after "received" and 
"corresponding" before 

"Signature Block", so the sentence reads:




 




    The collector may verify that the hash 
of

    each received syslog message matches the signed hash 
contained in the

    corresponding Signature Block.




 




 




 




Section 4.2.3: It is strongly suggested that the field currently 
identified as 

Signature Group (SG) be renamed to Signature Group 
Interpretation (SGI) to avoid 

confusion. The statement that SPRI identifies 
the actual signature group also 

comes a bit late (beginning of the fourth 
paragraph). It should be moved up to 

the first paragraph.




 




Note that changing SG to SGI affects the tables in section 4.2 and 5.3.2 
and IANA considerations. Note also that the field is called SIG instead of SG in 
section 5.3.2.3.

In section 5.3.2, P23, what's the main difference between 
using Signature block and using Certificate block? It seems Certificate Block 
overlaps with Signature Block, e.g., Both block are digitally signed, why is 
only certificate block termed "certificate block", why not term certificate 
block as "signature block"?




 




In section 5.3.2.9, the point is made that the timestamp of the Certificate 


Block message is the same as that of the Payload Block. In fact, they differ 


very slightly in the example. Is that intended?




 




In section 6, near the bottom of the first paragraph, a couple of words are 


missing. It is suggested that the sentence be changed to read:




 




                                                                     
The

    collector MUST ignore duplicates of Signature Blocks 
and 
Certificate

                          
^^^^^^^^^^^^^^

    Blocks it has already received and 
authenticated.




 




Section 7 is informative. Perhaps it belongs in an 
appendix.

 

In section 7.1, 

 4.  Set the last message 
number processed to the value of 
the

           First 
Message Number plus the Count of the Signature 
Block

           minus 
1.

Why is the Last message number not defined in this 
document?

 

In section 8.1,

 This specification uses Public 
Key Cryptography technologies.  The

   proper party or parties 
have to control the private key portion of a

   public-private key 
pair.  Any party that controls a private key can

   sign 
anything it pleases.

 

As regarding the last sentence, Is it 
appropriate to use "pleases" here? How about using *favors* or *prefers* instead 
of *pleases*?

 

In section 8.2,

As a signer, it is advisable to 
avoid message lengths exceeding 2048

   octets.  Various 
problems might result if a signer were to send

   messages with a 
length greater than 2048 octets, because relays MAY

   truncate 
messages with lengths greater than 2048 octets which would

   make 
it impossible for collectors to validate a hash of the packet.

   
To increase the chance of interoperability, it tends to be best to 
be

   conservative with what you send but liberal in what you are 
able to

   receive.

 

   From the above 
paragraph, we can see it is necessary to restrict

   the length of 
message, So I would like to suggest changing the last

   sentence 
as:

   "

   To increase the chance of 
interoperability, it tends to be best to 

   limit the length of 
what you send but loose what you are able to

   
receive.

   "

   to make it more precise. Is it 
reasonable to do this?

 

 

In section 8.3,

Syslog does not 
strongly associate the message with the message

   
originator.  That association is established by the collector 
upon

   verification of the Signature Block. 

   


What's the difference between associating the message with the message 
originator

and signature? If they are the same thing, I think the association 
should be pre-established

in collector? Is it a correct 
understanding?

 

 

In section 8.4,

Event messages might be 
recorded and replayed by an attacker.  Using

   the 
information contained in the Signature Blocks, a reviewer can

   
determine whether the received messages are the ones originally 
sent

   by an originator.  The reviewer can also identify 
messages that have

   been replayed.




 




I am wondering what the information is in the signature block can be used 
to

prevent replaying? Count or sequence number, time stamp, if there is such 
thing, it is better to

point it out which field of signature block is used 
for anti-replaying.

 

 

 

 




 




B. R.

Tina

http://tinatsou.weebly.com/contact.html