Subject: Re: [Syslog] Syslog-sign: Overlapping signature blocks

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

I don't see anything that would prohibit sliding windows?  Then again, I
don't see it mentioned particularly. Would probably not hurt to mention
it explicitly.  Perhaps some text in section 4.2.5, in conjunction with
discussion of First Message Number?  Similarly, in section 7.1, when
describing the algorithm, can include something along the line that we
need to maintain a cursor, indicating the highest message number that
was processed so far, and if the subsequent Signature Block message has
a smaller FMN, we "skip forward" accordingly.  

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, July 24, 2008 1:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Syslog] Syslog-sign: Overlapping signature blocks

Jon Callas wrote:

> Overlap of sliding windows is a feature, not a bug. If anything, we 
> should reverse the polarity on your comment and more explicitly 
> mention its utility.

I asked about this because some parts of the draft need small changes if
overlapping sliding windows are allowed (and I agree that they could be
useful).

In particular, Sections 7.1 and 7.2 seem to assume no overlap.

Best regards,
Pasi
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: <[email-masked]>
Date: Thu, 7 Aug 2008 22:40:12 +0300

Alexander Clemm wrote:

> I don't see anything that would prohibit sliding windows?  Then
> again, I don't see it mentioned particularly. Would probably not
> hurt to mention it explicitly.  Perhaps some text in section 4.2.5,
> in conjunction with discussion of First Message Number?  Similarly,
> in section 7.1, when describing the algorithm, can include something
> along the line that we need to maintain a cursor, indicating the
> highest message number that was processed so far, and if the
> subsequent Signature Block message has a smaller FMN, we "skip
> forward" accordingly.

The step "Skip all other Signature Blocks with the same First Message
Number" in the algorithm doesn't work well with overlap.

For example, a sliding-window implementation with rule "send signature
block after every 5 messages, and include at most 15 hashes in one
block" would, after rebooting, send signature blocks

FMN="1" CNT="5"
FMN="1" CNT="10"
FMN="1" CNT="15"
FMN="6" CNT="15"
FMN="11" CNT="15"

...where skipping the second and third signature block isn't the 
correct behavior.

Best regards,
Pasi