David,
Thank you for bringing this draft (back) to my attention. I want to
congratulate the authors on a generally well written document. DTLS is
an important missing component from the SYSLOG framework. I agree 110%
with the introduction, and perhaps would go further, that sometimes in
the worst of circumstances, it is important simply to try to get the
message out and hope someone hears it. What you will find from me below
are suggestions to simplify some text, most of which is non-normative.
I believe Section 5.1 is serving two masters, and in my experience, this
generally doesn't work well. Your first master is rationale behind
choice of transport. What you are reaching for here is a protocol
applicability statement. If you have the discussion about protocol
applicability, and nothing says that you even need to go there at this
stage, my suggestion would be to include it in your introduction and do
away with all of the sub-sub-headings in Section 5.1.
By way of example, I believe you are striving for relatively simple
statements a'la this:
In those circumstances where reliability or ordering is important,
SYSLOG over TLS is appropriate. As the Internet best runs on the
basis of appropriate resource sharing, SYSLOG over DTLS over DCCP is
defined in this document. For systems where DCCP is either not
available or not usable (such as the afformentioned situation), DTLS
over UDP is also defined.
Editorial:
s/has state such problems/has discussed (or addressed) this problem
Section 5.3:
1st para, 2nd sentence:
Why only RECOMMENDED?
2nd para, last sentence:
This document is assumed to apply to
future versions of DTLS, in which case the mandatory to implement
cipher suite for the implemented version MUST be supported.
Why do you need to say this at all?
3rd paragraph:
Both transport receiver and transport sender implementations MUST
provide means to generate a key pair and self-signed certificate in
the case that a key pair and certificate are not available through
another mechanism.
Why is this necessary? Isn't it sufficient to import and make use of a
self-signed certificate? Isn't it easy enough to run OpenSSL on a Mac
or linux box and import the stuff? I could see an argument for
usability concerns, but that's not sufficient grounds for a MUST.
An aside about your 2119 language: I haven't reviewed all of it, nor am
I an 2119 expert, but I can say that you will confuse people when you
use MUST, SHALL, and REQUIRED.
Section 5.3.2, 2nd para, last sentence:
The security parameters SHOULD be checked against the
security requirements of the requested session to make sure that the
resumed session provides proper security.
I think what you are aiming at here is a downgrade attack. First, isn't
this covered in DTLS? Otherwise, here I would argue for a MUST, and I
would be more clear about what you are protecting against, such as the
following:
In order to avoid downgrade attacks, an exiting session MUST NOT be
reused if its protection does not match the minimum policy
requirements of the new SYSLOG over DTLS session request.
Editorial:
Same section ABNF: is it not customary to use lower case, particularly
for non-terminals?
Again, thanks to the authors for putting this out there.
Eliot
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
