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