[secdir] secdir review of draft-ietf-syslog-sign-27

[Tina TSOU <[e-mail]>]

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