Signed Syslog Messages
draft-ietf-syslog-sign-29

I agree with Lars on Blind retransmissions. The document seems to be ecouraging this and, while there is a configuration parameter noted, it is unclear whether this is mandatory to implement, and to what value certInitialRepeat should default.

It seems to me that this mechanism is a bit of a hack.

My first point was a part of the DISCUSS. I am clearing in anticipation of an RFC Editor note. I've moved it here so that it doesn't disappear from the tracker.

1)
There is one point which is not entirely clear to me. So I would like to discuss it before recommending approval of this document:


5.2.2.  Signer Authentication and Authorization

   b.  X.509 end-entity certificate matching: The collector is
       configured with information necessary to identify the valid end-
       entity certificates of its valid peers, and for each peer, the
       HOSTNAME(s) it is authorized to use.

 [...]

       For each peer, the collector MUST support specifying a list of
       HOSTNAME(s) this peer is allowed to use either as FQDNs or IP
       addresses.

How can this MUST be achieved?
Is this again a requirement on management tools? Authors replied that that is the case, but I don't think this is entirely clear from the text.
I think using "collector" to convey this is too subtle.

I would be happy with an extra sentence saying that this is a requirement on management tools, or at least a pointer to the document that defines "collector" as being a management tool.

       Other forms of HOSTNAMEs are beyond the scope of this
       specification.

2)
5.3.2.9.  Example

   <110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd
   2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587"
   INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ
   NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z
   cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr
   AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m
   N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry
   5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM
   gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC
   ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF
   RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg=="
   SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]

It would have been good to see an example of Payload block split into
2 separate Certificate blocks.

3)
9.2.  Version Field

   The third registry that IANA is requested to create is entitled
   "syslog-sign signature scheme values".  It is for the values of the
   Signature Scheme subfield.  The Signature Scheme subfield constitutes
   the fourth octet in the Version field of Signature Blocks and
   Certificate Blocks.  New values shall be assigned by the IANA using
   the "IETF Consensus" policy defined in [RFC5226].  Assigned values
   are to be increased by 1, up to a maximum value of "9".

   This means
   that the same Signature Scheme value can be reserved for different
   Protocol Versions, possibly in each case referring to a different
   Signature Scheme each time.

This doesn't follow from the previous sentence.
I think there is a missing sentence before this one:

 "The values are registered relative to the Protocol Version."

   This makes it possible to deal with
   future scenarios in which the single octet representation becomes a
   limitation, as more Signature Schemes can be supported by defining
   additional Protocol Versions that implementations might support
   concurrently.

This draft is very hard to understand. I think it needs some high level box and arrows level description of how it works would help implementers get it right.

In the text above '... implementes MAY consider ...' the MAY should not be capitalized to be consistent with the other 'may' statements in the same paragraph.

I tried to search the document for an explanation of what the
reassembly algorithm is for fragmentation, but found very little material.
On IP we always forgot to specify some safety checks such as prohibiting
overlapping fragments, and had to patch specifications and implementations
later. Perhaps these should be specified here on the first go around?
Or is the situation with syslog different from IP? I admit that there's
probably no firewalls in syslog that were one reason why fragmentation
rules had to be constructed so carefully.

Section 1., paragraph 6:
>    The mechanism described in this specification is intended to be used
>    in conjunction with the syslog protocol as defined in [RFC5424] as
>    its message delivery mechanism and uses the concept of STRUCTURED-
>    DATA elements defined in that document.  In fact, this specification
>    mandates implementation of syslog protocol.  Nevertheless, it is
>    conceivable that the concepts underlying this mechanism could also be
>    used in conjunction with other message delivery mechanisms.
>    Designers of other efforts to define event notification mechanisms
>    are therefore encouraged to consider this specification in their
>    designs.

  I don't think it's appropriate for the IETF to make a blanket
  recommendation for this mechanism for other event notifiation systems.
  (I note that the IETF already has other message signing mechanism that
  SYSLOG also did not pick, and probably for good reason.)


Section 3., paragraph 3:
>    While syslog signer and collector implementations MAY support
>    messages with a length larger than 2048 octets, implementers need to
>    be aware that any message truncations that occur render the mechanism
>    useless.

  Wouldn't it make more sense to say that this mechanism MUST NOT be
  applied to messages > 2048 octets, in order to avoid invalid signature
  warnings on the receiver?


Section 5.3.1., paragraph 2:
>    Because certificates can legitimately be much longer than 2048
>    octets, the Payload Block can be split up into several pieces, with
>    each Certificate Block carrying a piece of the Payload Block.  Note
>    that the signer MAY make the Certificate Blocks of any legal length
>    (that is, any length that keeps the entire Certificate Block message
>    within 2048 octets) that holds all the required fields.  Software
>    that processes Certificate Blocks MUST deal correctly with blocks of
>    any legal length.  The length of the fragment of the Payload Block
>    that a Certificate Block carries MUST be at least 1 octet.  The
>    length SHOULD be chosen such that the length of the Certificate Block
>    message does not exceed 2048 octets.

  See above - for reliability reasons, I think 480 octets are a better
  size limit.


Section 5.3.2., paragraph 0:
> 5.3.2.  Certificate Block Format and Fields

  Is there sufficient information in the payload and certificate fields
  to reassemble a fragmented payload block after retransmission under
  loss?


Section 8.2., paragraph 1:
>    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.

  See above, this limit should be 480.

Section 8.5 states:   "... a reviewer can pinpoint any messages sent by the originator but not
received by reviewing the signature block information."  I don't think this is quite correct.
Since the signature block indicates only the first message number, a reviewer can determine
(a) that one or more messages are missing, and (b) the range in the sequence that particular
message falls in.  The specific missing message can only be determined if it is the first
message in the signature group or the set of messages was sequential (e.g., if the signature
group included messages 3,4,5,6,... and 5 is missing that could be determined).

Anyway, I think the word "pinpoint" is misleading.