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

Tina TSOU <tena@huawei.com> Wed, 16 September 2009 02:40 UTC

Return-Path: <tena@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 39EED28C11F; Tue, 15 Sep 2009 19:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.237
X-Spam-Status: No, score=-98.237 tagged_above=-999 required=5 tests=[AWL=2.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5jQXS8-QA1Er; Tue, 15 Sep 2009 19:40:32 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown []) by core3.amsl.com (Postfix) with ESMTP id 4E64228C118; Tue, 15 Sep 2009 19:40:32 -0700 (PDT)
Received: from huawei.com (szxga01-in []) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1003I7M4L86@szxga01-in.huawei.com>; Wed, 16 Sep 2009 10:41:09 +0800 (CST)
Received: from huawei.com ([]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1002IHM4LA2@szxga01-in.huawei.com>; Wed, 16 Sep 2009 10:41:09 +0800 (CST)
Received: from z24109b ([]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ1003Q0M4L8A@szxml04-in.huawei.com>; Wed, 16 Sep 2009 10:41:09 +0800 (CST)
Date: Wed, 16 Sep 2009 10:41:08 +0800
From: Tina TSOU <tena@huawei.com>
To: iesg@ietf.org, secdir <secdir@ietf.org>
Message-id: <006801ca3677$25943b00$8e27460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: multipart/alternative; boundary="Boundary_(ID_XWfkaXsoKfeIzi4JDxE8Mw)"
X-Priority: 3
X-MSMail-priority: Normal
References: <4AAE56EF.5080002@ieca.com>
Cc: draft-ietf-syslog-sign-27@tools.ietf.org, syslog-chairs@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-syslog-sign-27
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2009 02:40:34 -0000

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
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 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
   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
   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.