Subject: [Syslog] Syslog-sign: 6.2. Flexibility

From: Martin Schütte <[email-masked]>
Date: Fri, 01 Aug 2008 23:51:56 +0200

Hello,
is section 6.2. (Flexibility) still relevant?
I have the impression all of its statements refer to older versions and 
are obsolete in the current protocol.

    An originator may change many things about the makeup of Signature
    and Certificate Blocks in a given reboot session.  The things it
    cannot change are:
       * The version
       * The number or arrangements of Signature Groups

Question 1: Is there anything left that can be changed inside a reboot 
session? Only the redundancy, but that is always discussed in 6.1.

Question 2: Is there any reason to prevent any change? IMO no.
I would say a Signature Group is defined by the values of HOSTNAME, VER, 
RSID, SG, and SPRI.
So if an originator has only one signature group and suddenly uses 
different values for some Blocks then these Blocks simply will not 
belong to the same signature group. No need to introduce the concept of 
  change only to forbid it.

    It is legitimate for an originator to send short Signature Blocks to
    allow the collector to verify messages quickly.

Signature Blocks are variable in length. Allowing a short one is 
meaningless.

-- 
Martin
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 1 Aug 2008 18:32:33 -0700

Martin,

to clarify what you are suggesting - are you suggesting to strike section 6.2 and change the title of 6 to "Redundancy"?  I think the entire section is in essence informational; per se I would have no issues taking it out.  

Now, regarding question 2:  I am not clear about what you are asking.  How a signature group is defined is ultimately up to an administrator (specifically if SG fields are 2 or 3).  It is probably not a good idea to change these on the fly, although it probably does not need to be prohibited.  Should this issue be discussed in a separate statement somewhere?  (Basically, it would state something along the lines that while it is possible to change how Signature Groups are configured, adminstrators need to be aware of the implications.)  

The statement at the end of 6.2 states that it is legitimate for an originator to send short Signature Blocks to allow the collector to verify messages quickly (and not have to wait until a Signature Block is "filled up").  Precisely because the block are variable in length this is possible.  So, I am not clear what the issue would be with that statement?

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Schütte
Sent: Friday, August 01, 2008 2:52 PM
To: [email-masked]
Subject: [Syslog] Syslog-sign: 6.2. Flexibility

Hello,
is section 6.2. (Flexibility) still relevant?
I have the impression all of its statements refer to older versions and are obsolete in the current protocol.

Question 1: Is there anything left that can be changed inside a reboot session? Only the redundancy, but that is always discussed in 6.1.

Question 2: Is there any reason to prevent any change? IMO no.
I would say a Signature Group is defined by the values of HOSTNAME, VER, RSID, SG, and SPRI.
So if an originator has only one signature group and suddenly uses different values for some Blocks then these Blocks simply will not belong to the same signature group. No need to introduce the concept of
  change only to forbid it.

Signature Blocks are variable in length. Allowing a short one is meaningless.

---

From: Martin Schütte <[email-masked]>
Date: Mon, 04 Aug 2008 16:04:49 +0200

Alexander Clemm (alex) schrieb:
> to clarify what you are suggesting - are you suggesting to strike
> section 6.2 and change the title of 6 to "Redundancy"?  I think the
> entire section is in essence informational; per se I would have no
> issues taking it out.

Yes.

> Now, regarding question 2:  I am not clear about what you are asking.
> How a signature group is defined is ultimately up to an administrator
> (specifically if SG fields are 2 or 3).  It is probably not a good
> idea to change these on the fly, although it probably does not need
> to be prohibited.  Should this issue be discussed in a separate
> statement somewhere?  (Basically, it would state something along the
> lines that while it is possible to change how Signature Groups are
> configured, adminstrators need to be aware of the implications.)

Of course every change will require a new reboot session and the sending 
of new Certificate Blocks, so the receiver/verifier will be able to notice.
Given that I do not see a difference between a config change "on the 
fly" and restarting the server/daemon with the new configuration.

> The statement at the end of 6.2 states that it is legitimate for an
> originator to send short Signature Blocks to allow the collector to
> verify messages quickly (and not have to wait until a Signature Block
> is "filled up").  Precisely because the block are variable in length
> this is possible.  So, I am not clear what the issue would be with
> that statement?

It is no big deal.
I just found it irritating and wondered if there were also long blocks.
Maybe it would be better to add a remark to section 4 (Signature Blocks) 
stating that the originator is free to decide when to send Signature 
Blocks, how many hashes they contain and if/how he adds redundancy.

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 4 Aug 2008 16:29:37 -0700

Hi Martin,

ok, unless others raise objections I'll change title of 6 to redundancy and strike 6.2. I'll retain mention of the fact somewhere that the originator is free to decide when to send signature blocks, something that might even be subject to configuration.  I'll also have a statement somewhere about that change in configuration of signature groups needs to coincide with start of new reboot sessions.  

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Schütte
Sent: Monday, August 04, 2008 7:05 AM
To: [email-masked]
Subject: Re: [Syslog] Syslog-sign: 6.2. Flexibility

Yes.

> idea to change these on the fly, although it probably does not need to 
> be prohibited.  Should this issue be discussed in a separate statement 
> somewhere?  (Basically, it would state something along the lines that 
> while it is possible to change how Signature Groups are configured, 
> adminstrators need to be aware of the implications.)

Of course every change will require a new reboot session and the sending of new Certificate Blocks, so the receiver/verifier will be able to notice.
Given that I do not see a difference between a config change "on the fly" and restarting the server/daemon with the new configuration.

It is no big deal.
I just found it irritating and wondered if there were also long blocks.
Maybe it would be better to add a remark to section 4 (Signature Blocks) stating that the originator is free to decide when to send Signature Blocks, how many hashes they contain and if/how he adds redundancy.