Last Call Review of draft-ietf-syslog-sign-

Request Review of draft-ietf-syslog-sign
Requested rev. no specific revision (document currently at 29)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-15
Requested 2009-09-03
Authors Alexander Clemm, Jon Callas, John Kelsey
Draft last updated 2009-09-18
Completed reviews Secdir Last Call review of -?? by Tina Tsou
Secdir Telechat review of -?? by Tina Tsou
Assignment Reviewer Tina Tsou 
State Completed
Review review-ietf-syslog-sign-secdir-lc-tsou-2009-09-18
Review completed: 2009-09-18


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

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 

    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 

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, 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:



    collector MUST ignore duplicates of Signature Blocks 


    Blocks it has already received and 


Section 7 is informative. Perhaps it belongs in an 


In section 7.1, 

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

Message Number plus the Count of the Signature 


Why is the Last message number not defined in this 


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

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

messages with lengths greater than 2048 octets which would

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

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

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



   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



   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



   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 

   verification of the Signature Block. 


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

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

in collector? Is it a correct 



In section 8.4,

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

information contained in the Signature Blocks, a reviewer can

determine whether the received messages are the ones originally 

   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 

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.