[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] Detailed Review Comments on Syslog Protocol -09 - Part III
Sharon,
some more comments... I've [snip]ed some things out that are now in
separate threads.
Rainer
> >
> > S18. In section 6.5, the example, the 2 space thing is
> > inconsistent with
> > previous use of "-" character to indicate no value. Is there
> > a reason for
> > this and why is this buried in an example?
>
> This is a result of the ABNF. So far, we have not defined that the
> non-existence of any STRUCTURED-DATA must be denoted by
> anything. As such,
> it is SP <empty STRUCUTRED-DATA> SP, ultimately leading to
> two SP after each
> other.
>
> If you feel we should explicitly denote missing
> STRUCTURED-DATA (and nobody
> objects), I can add this. "-" would be appropriate in this
> case, because it
> is used everywhere else in the draft for this purpose.
>
> </Rainer>
<Sharon>
>
> No, the structured data should just not be there if it is
> optional and not
> supported. What I was referring to was text like the
> following in 6.2.7:
> "The dash ("-") is a reserved SENDER-INST field value that
> MUST only be used
> to indicate an unidentified instance." and in section 6.5
> "Note the two SP
> characters following MSGID. The second SP character is the
> STRUCTURED-DATA
> delimiter. It tells that no STRUCTURED-DATA is present in
> this message."
>
> What I was trying to do was 1) Get us to realize the syntax
> between the two
> was different and ensure we had a good reason for that 2) Get the
> description of this interpretation of the two SP character
> moved up into a
> more appropriate part of the document
</Sharon>
I changed the definition so that a "-" is now defined for empty
STRUCTURED-DATA. You are right, this is more consistent with the rest of
the spec and it is less error-prone/confusing.
[snip]
> <Rainer>
> > S21. As a general comment to the 7.1.* sections, it would
> > seem that the
> > optionality of the parameter has been confused with the
> > optionality of its
> > behaviour. If the SD-PARAM is present, the behaviour MUST be
> > as described.
>
> Actually, I thought this was in the question. Maybe this is a language
> issue. Could you point me to what exactly makes the behaviour
> optional (it
> was not intended to be).
> </Rainer>
>
<Sharon>
> Since section 7.1 indicates the optionality of timeQuality,
> the text in
> 7.1.1 needs to be written such that if you support
> timeQuality, then this is
> way that tzKnown MUST be supported. If tzKnown is considered
> optional even
> if timeQuality is supported, then a separate statement
> indicating that it
> SHOULD be support should be made and the following sentences
> reworked to be
> 'if it is support...'
>
> "The "tzKnown" parameter indicates if the original sender knows its
> time zone. If it does so, the value "1" MUST be used. If the time
> zone information is in doubt, the value "0" MUST be used. If the
> sender knows its time zone but decides to emit time in
> UTC, the value
> "1" MUST be used (because the time zone is known)."
</Sharon>
OK, now I understand. There were MUSTs in there in the past, but it was
suggested that they become SHOULDs. No other voice at that time. I've
reconsidered based on your arguments and changed it back to MUSTs. If
somebody is unhappy with this, pleas provide me with a good argument why
It must be a SHOULD ;)
I've also added a general sentence in the description of the SD-ID that
all parameters are optional. I think this is sufficient and we do not
need to say that again in any parameter.
[snip]
> <Rainer>
> >
> > S24. In section 8, a general note on the security
> > considerations section is
> > that a lot of the content is not. The non-security
> > considerations content
> > should be moved elsewhere or reworked to be an actual security
> > consideration. Also, there appears to be requirements buried
> > in here, which
> > also does not seem appropriate.
> >
> > S24.1 The last paragraph in section 8.1 is not a security
> > consideration.
>
> I think it is, but I may be wrong: my intention was to warn
> against too
> verbose logging, because it is very often seen that logging
> is turned off if
> it is too verbose. Does this really not fit in here?
> </Rainer>
>
<Sharon>
> The text in question is
>
> " Besides this risk, diagnostic message, if they occur too frequently,
> can become meaningless. Common practice is to turn off diagnostic
> logging if it is too verbose. This potentially removes important
> diagnostic information which could aid the operator."
>
> It doesn't really say what you are saying. Plus, intelligent
> filtering can
> ensure the correct bits are what gets filtered out.
</Sharon>
I've changed the text:
####
Besides this risk, too verbose diagnostic logging can cause
the administrator to turn logging off at all.
####
I am not talking about intelligent filtering, because especially the
small to mid sized shops (and their operators) in my experience do not
use it. They turn off logging to "fix" the "issue". It's not smart, but
its my real-world experience (keep in mind I am not talking about the
big guys...).
<Sharon>
> <Rainer>
>
> > S24.2 The third paragraph in section 8.2 defines requirements.
>
> I think I can simply change the "SHOULD NOT" to lower case -
> storage is
> beyond the scope of this document. Or should I actually drop
> it - but it
> *is* a very important security issue...
>
> </Rainer>
>
> I seem to have a very different definition of a security
> considerations
> section than you do. I can't advise.
</Sharon>
Can anybody else provide an argument why this is not a security
consideration? I will change, but I honestly do not see why it is none.
In my experience, attacks like the one described are being used in the
real world and cause log data to become invisible. Maybe the issue is
that it is something that does not happen on the wire?
>
> > S24.4 Sections 8.4, 8.5, 8.6 & 8.7 don't appear to be security
> > considerations.
>
> Why is 8.4 not a security consideration? [honest question,
> not suggestively
> meant ;)]
>
> 8.5 to 7.7 are carried over from RFC 3164. They are security
> considerations
> there, too. Why shouldn't they apply here?
> </Rainer>
<Sharon>
>
> You have not commented on 8.6.
>
> Ok. perhaps this would help: For each of the sections ask
> yourself 'why is
> this a security' consideration and ensure the answer gets
> published. Also
> make sure you don't define requirements (upper or lower case).
>
</Sharon>
8.5/6/7 are now removed. They are also obsoleted because we now have the
sequenceID.
> <Rainer>
> > S24.5 Also the last sentence in the first paragraph of 8.4
> > seems completely
> > off topic.
>
<Sharon>
> syslog is simplex delivery. nobody will notice if the message
> is lost. This
> is telling the fact and informing the implementer that the
> protocol might
> not be suitable for a specific application. Should I still drop it?
> </Rainer>
>
> Again, ensure the 'why this is a security consideration' is included.
</Sharon>
OK, you are right. I think it is something that one needs to look at,
but it does not really belong to the context of 8.4. Removed that
sentence. The information is present at other places, too.
>
> <Rainer>
> >
> > S25. In section 8.12, the last sentence, what is it saying?
> > What does a
> > reliable transport mapping mechanism have to do with operator
> > error? This
> > claims that 'Using a reliable transport mapping can guard
> > against these
> > problems' How?
>
> A reliable transport mechanism with notifications (e.g. RFC
> 3195/COOKED) can
> detect such loops. Thus it can guard against them.
> </Rainer>
<Sharon>
> Add to draft.
</Sharon>
I added:
####
Using a reliable transport mapping can help identify these problems.
####
Rainer
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec