Hi John,
At 01:35 PM 11/20/00 -0500, John Kelsey wrote:
---some deleted---
>Okay, so I've spent some time thinking about this (along
>with writing a much bigger document than I intended to
>describe syslog-auth as I see it, hopefully to be sent out
>real soon now)
(Before I started, I could'a sworn that a totally complete ID
on syslog would not have been more than 5 pages... ;-)
>, and it looks to me like the only way to do
>end-to-end message signatures that work for all lengths of
>messages is to include signature blocks every N messages. I
>visualize this as something like this:
>
>For a given signing session, we generate a reboot session ID
---some deleted---
Are you proposing to have a hash included within each message
as well as a signing block? That makes sense, but it wasn't
entirely clear from what you wrote here.
---some deleted---
>It's simple enough to add redundancy to this. For example,
>we can send a signature block every 17 messages, and have
>each syslog block carry the hashes of the previous 17 and
>next 17 messages. But it's also easy enough to see that as
>long as we don't have reliable message delivery, we will
>have some chance of not being able to verify some messages.
And then you also have the case of multiple signature blocks being
lost. Either proposal ("past-34" or "past-17+next17") sounds like
it will well cover what we have in the charter.
>The big question to me is how we can encode this signature
>block so that it will always be forwarded to the same place
>as the messages associated with it are forwarded. Is there
>any way to reliably do this?
I think that would be an implementation issue. The import thing
in the ID is the description of the signature block and its
usage. It should be noted in the ID that it will only be useful
if it is received by the devices receiving the syslog messages.
I'd suggest keeping it within the syslog format; perhaps using
<46> = syslogd facility + informational severity.
Alex wrote:
>...
>>What about combining compression and encryption to squeeze a
>>full payload with signature etc into the UDP PDU?
>
>Hmmm. I guess I don't see what this buys us. There are two
>situations:
---some deleted---
>b. We're sending from a syslog-auth sender to an old-style
>receiver. In this case, we can't use compression or
>encryption without making the message incomprehensible to
>the receiver, and we can't do much compression without
>using illegal characters in ths messages. (We also can't
>guarantee that all legal message texts will compress well
>enough that a base 64 encoded version of the compressor
>output will be smaller than the original message text.)
>
>What am I missing?
Both encryption and compression make the message unreadable to
packet sniffers. I don't think that we want to change that
behaviour.
Thanks,
Chris
