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

[Tina TSOU <[e-mail]>]

Sending to [e-mail]


B. R.
Tina
http://tinatsou.weebly.com/contact.html

  ----- Original Message ----- 
  From: Tina TSOU 
  To: [e-mail] ; secdir 
  Cc: [e-mail] ; [e-mail] 
  Sent: Wednesday, September 16, 2009 10:41 AM
  Subject: [secdir] secdir review of draft-ietf-syslog-sign-27


  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






------------------------------------------------------------------------------


  _______________________________________________
  secdir mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/secdir