Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2

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

[email-masked] schrieb:
> Is it possible to sign the same set of messages with multiple
> algorithms (by sending multiple Payload and Signature Blocks) to
> provide smooth algorithm transition?

I think it should be possible.
A message can belong to multiple signature groups, so an originator 
could e.g. use one signature group with SG="0" and VER="0111" and a 
second one with SG="0" and VER="0121".

This leads me to a problem in 4.2.3.: "In all cases, no more than 192 
distinct Signature Groups (0-191) are permitted."

IMHO that should be removed or changed to "In all cases, no more than 
192 distinct SPRI values (0-191) are permitted."

Such a limit would clearly prevent using parallel versions for SG="1".
Or in another scenario: my syslogd uses SG="3" to assign one signature 
group per destination. So that limit would prevent the use of more than 
192 destinations.

> Section 4.2.5: When counting messages for the "First Message Number"
> field, are Signature Blocks and Certificate Blocks also counted?

Whether the FMN counts syslog-sign messages depends on whether these are 
hashed and included in Signature Blocks.

> Should earlier Signature Block and/or Certificate Block messages
> be included in Hash Blocks?

4.1:
    The syslog messages defined as part of syslog-sign themselves
    (Signature Block messages and Certificate Block messages) do not need
    to be signed by a Signature Block.  Collectors that implement syslog-
    sign know to distinguish syslog messages that are associated with
    syslog-sign from those that are subjected to signing and process them
    differently.

I guess there are arguments for both positions but IMHO syslog-sign 
messages should not be hashed and included because
a) I see syslog-sign as a kind of session-layer that should disappear 
after the verification is done and some log-analyzer (=application 
layer) takes over, and
b) the verifier will have to know to treat them differently anyway and 
leaving them out avoids several problems and special cases.

Either way the standard has to decide for one position to ensure 
interoperability. Otherwise one might have a sender that does include 
hashes of syslog-sign messages in its Signature Blocks and a verifier 
that will not check them but report lost messages.

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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 1 Aug 2008 19:25:26 -0700

Hi,

please see inline, delimited <ALEX>

--- 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: Re: [Syslog] Syslog-sign: Minor clarifications, part 2

I think it should be possible.
A message can belong to multiple signature groups, so an originator could e.g. use one signature group with SG="0" and VER="0111" and a second one with SG="0" and VER="0121".

<ALEX> 
The same message can be in multiple signature groups and hence be signed multiple times.  It is also possible to define multiple signature groups so that each contain exactly the same messages (e.g. SG="3", which basically means administrator-defined which would be anything).  

This leaves the question whether it should be possible to sign the *same* signature group with multiple algorithms.  There are currently no provisions for that.  The spec also states that a payload block (containing the certificate information) is valid for the entire reboot session - we currently do not allow to change it during a reboot session.  If this is an issue, it will have some ramifications.  One way to deal with it would be to change the way a "reboot session" is defined.  

Thoughts?  
</ALEX>

This leads me to a problem in 4.2.3.: "In all cases, no more than 192 distinct Signature Groups (0-191) are permitted."

Such a limit would clearly prevent using parallel versions for SG="1".
Or in another scenario: my syslogd uses SG="3" to assign one signature group per destination. So that limit would prevent the use of more than
192 destinations.

<ALEX>
I am not sure I understand the issue?  The fact that the SPRI parameter may take only values from 0-191 inclusive already implies there can be no more than 192 values?  I think the statement is correct as is - the signature group refers to a set of syslog messages while the SPRI value defines what messages that set contains - we do however want to call out that there can be no more than 192 such sets.  
</ALEX>

> field, are Signature Blocks and Certificate Blocks also counted?

Whether the FMN counts syslog-sign messages depends on whether these are hashed and included in Signature Blocks.

> Should earlier Signature Block and/or Certificate Block messages be 
> included in Hash Blocks?

4.1:

I guess there are arguments for both positions but IMHO syslog-sign messages should not be hashed and included because
a) I see syslog-sign as a kind of session-layer that should disappear after the verification is done and some log-analyzer (=application
layer) takes over, and
b) the verifier will have to know to treat them differently anyway and leaving them out avoids several problems and special cases.

Either way the standard has to decide for one position to ensure interoperability. Otherwise one might have a sender that does include hashes of syslog-sign messages in its Signature Blocks and a verifier that will not check them but report lost messages.

<ALEX>
Section 4.1 states that syslog-sign messages are not counted and not signed, so I think the current position is clear.  Martin, I agree with your reasoning and argumentation.  Essentially, the purpose is to sign a stream of messages, not alter that stream of messages.
</ALEX>

---

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

Alexander Clemm (alex) schrieb:
> This leaves the question whether it should be possible to sign the
> *same* signature group with multiple algorithms.  There are currently
> no provisions for that.  The spec also states that a payload block
> (containing the certificate information) is valid for the entire
> reboot session - we currently do not allow to change it during a
> reboot session.  If this is an issue, it will have some
> ramifications.  One way to deal with it would be to change the way a
> "reboot session" is defined.
> 
> Thoughts? </ALEX>

To allow multiple algorithms inside one signature group then one could 
use multiple SIGN params with prefixes to identify their algorithm. E.g. 
[ssign ... SIGN="1;<base64 signature DSA/SHA-1>" SIGN="2;<base64 
signature DSA/SHA-256>"].

But I do not like the concept.
Just using two Signature Groups in parallel allows the same thing with 
greater flexibility and simpler implementations. (Maybe with more 
messages, but that is not negative for a protocol that has to be 
redundant by design,)

> <ALEX> I am not sure I understand the issue?

I think the problem is we have different concepts of a "Signature 
Group". A definition would be useful.

The Introduction states "A Signature Group identifies a group of 
messages that are all kept together for signing purposes by the originator."
I would add the list of attributes that I consider the actual 
identifiers: (HOSTNAME, APP-NAME, PROCID, MSGID, VER, RSID, SG, SPRI).

It follows: Two syslog-sign messages with the same values for these 
fields belong to the same Signature Group. Two syslog-sign messages 
which values differ in any of these fields do not belong to the same 
Signature Group.

>  The fact that the SPRI
> parameter may take only values from 0-191 inclusive already implies
> there can be no more than 192 values?

Yes, indeed.
But that makes the sencence only more confusing, because what do the 
given numbers 0-191 mean if they do not refer to SPRI values?

   I think the statement is
> correct as is - the signature group refers to a set of syslog
> messages while the SPRI value defines what messages that set contains
> - we do however want to call out that there can be no more than 192
> such sets. </ALEX>

I am sorry if this appears like nit-picking, but do you say
- There can be no more (=follows logically from the 
definitions/construction)? or
- There should be no more (=there could be, but we set an arbitrary 
upper limit for interoperability)?

Maybe we can use an example to test the limits:
Say I want to use VER="0111" and VER="0121" in parallel so I have every 
message signed twice. And I also want to use SG="1". Then I have 384 
concurrent Signature Groups.  Ennumerating with the identifies as above 
(HOSTNAME, APP-NAME, PROCID, MSGID are constant) gives the list:
   1. (..., VER="0111", RSID="123", SG="1", SPRI="0")
   2. (..., VER="0111", RSID="123", SG="1", SPRI="1")
...
192. (..., VER="0111", RSID="123", SG="1", SPRI="191")
193. (..., VER="0121", RSID="123", SG="1", SPRI="0")
194. (..., VER="0121", RSID="123", SG="1", SPRI="1")
...
384. (..., VER="0121", RSID="123", SG="1", SPRI="191")

Should this be a valid protocol use or not?

 > <ALEX> Section 4.1 states that syslog-sign messages are not counted
> and not signed, so I think the current position is clear.  Martin, I
> agree with your reasoning and argumentation.  Essentially, the
> purpose is to sign a stream of messages, not alter that stream of
> messages. </ALEX>

Could we replace "do not need to be signed" by "MUST not be signed" then?

---

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

Thinking a little more about it, I am not sure if we the requirement to sign the same signature group with multiple algorithms by the same originator.  If we allow for multiple originators on the same host as I think we are saying we would, they each can have their own definitions of the same signature group and use a different algorithm.   Likewise, a single originator can define two signature groups with separate SPRIs that include the same messages, and sign each of them with a different algorithm.  With those capabilities, the space should be well covered, and in practice should be able to accomplish everything that we could by allowing multiple algorithms for the same signature group using the same identifier from the same originator on the same host, without requiring the associated completiy.  With this, I think the remainder of the issues you bring up are moot.  

On the last item, agree, let's make it "MUST NOT be signed".  

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Schütte
Sent: Monday, August 04, 2008 6:50 AM
To: [email-masked]
Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2

Alexander Clemm (alex) schrieb:
> reboot session.  If this is an issue, it will have some ramifications.  
> One way to deal with it would be to change the way a "reboot session" 
> is defined.
> 
> Thoughts? </ALEX>

To allow multiple algorithms inside one signature group then one could use multiple SIGN params with prefixes to identify their algorithm. E.g. 
[ssign ... SIGN="1;<base64 signature DSA/SHA-1>" SIGN="2;<base64 signature DSA/SHA-256>"].

But I do not like the concept.
Just using two Signature Groups in parallel allows the same thing with greater flexibility and simpler implementations. (Maybe with more messages, but that is not negative for a protocol that has to be redundant by design,)

> <ALEX> I am not sure I understand the issue?

I think the problem is we have different concepts of a "Signature Group". A definition would be useful.

The Introduction states "A Signature Group identifies a group of messages that are all kept together for signing purposes by the originator."
I would add the list of attributes that I consider the actual
identifiers: (HOSTNAME, APP-NAME, PROCID, MSGID, VER, RSID, SG, SPRI).

It follows: Two syslog-sign messages with the same values for these fields belong to the same Signature Group. Two syslog-sign messages which values differ in any of these fields do not belong to the same Signature Group.

> there can be no more than 192 values?

Yes, indeed.
But that makes the sencence only more confusing, because what do the given numbers 0-191 mean if they do not refer to SPRI values?

   I think the statement is
> correct as is - the signature group refers to a set of syslog messages 
> while the SPRI value defines what messages that set contains

I am sorry if this appears like nit-picking, but do you say
- There can be no more (=follows logically from the definitions/construction)? or
- There should be no more (=there could be, but we set an arbitrary upper limit for interoperability)?

Maybe we can use an example to test the limits:
Say I want to use VER="0111" and VER="0121" in parallel so I have every message signed twice. And I also want to use SG="1". Then I have 384 concurrent Signature Groups.  Ennumerating with the identifies as above (HOSTNAME, APP-NAME, PROCID, MSGID are constant) gives the list:
   1. (..., VER="0111", RSID="123", SG="1", SPRI="0")
   2. (..., VER="0111", RSID="123", SG="1", SPRI="1") ...
192. (..., VER="0111", RSID="123", SG="1", SPRI="191") 193. (..., VER="0121", RSID="123", SG="1", SPRI="0") 194. (..., VER="0121", RSID="123", SG="1", SPRI="1") ...
384. (..., VER="0121", RSID="123", SG="1", SPRI="191")

> agree with your reasoning and argumentation.  Essentially, the purpose 
> is to sign a stream of messages, not alter that stream of messages. 
> </ALEX>

---

From: Martin Schütte <[email-masked]>
Date: Tue, 05 Aug 2008 03:58:57 +0200

Alexander Clemm (alex) schrieb:
> completiy.  With this, I think the remainder of the issues you bring
> up are moot.

I'm sorry, but only my first few lines were about the multiple signatures.

The definition of a "signature group" and a possible limit of their 
number is a fundamental issue and should be discussed.
Especially with our obviously different conceptions based on the same 
specification.