Hi, Rainer, Thanks for your thorough review!
Some responses are inline. > ------------------------------------- > 3.0 > == > The security service is also applicable to BSD Syslog defined in > RFC3164 [7]. But, it is not ensured that the protocol > specification > defined in this document is applicable to BSD Syslog. > == > > Do we really intend to support RFC 3164-style syslog (read: > nothing known about the message format) over this transport? > If so, the consequence is that implementations of > -transport-tls must check for > 3164 format and eventually be able to handle it. > > I suggest removing these two sentence, as it looks we > encourage that case. If they stay, we should clearly state > that a receiver is NOT REQUIRED to implement this. > Agreed. More comments from WG is welcome! > ------------------------------------- > Section 4.3, inside the ABNF: > > > SP = " " > > I think this is problematic in respect to 2.4 of RFC 4234. I > suggest replacing by > > SP = %d32 > I checked the ABNF with: http://rtg.ietf.org/~fenner/abnf.cgi It seems the tools suggest to use " " rather than %d32. I checked RFC4234, it says that it permits the specification of literal text strings directly, enclosed in quotation-marks. I will changed it back to %d32 to keep it consitent with the syslog protocol. > ------------------------------------- > 5.1 > > == > When confidentiality is a concern, a sender/relay MUST authenticate > the receiver to make sure it is talking to the right peer. > == > > I do not find the MUST is appropriate here: "when > confidentiality is a concern" is not a hard fact. What does > it mean? When MUST I implement authentication. Is my > Implementation not compliant to this doc if I have the wrong > understanding of "when confidentiality is a concern". Or MUST > I always implement it, because confidentiality is probably > very often a concern? > > I think this is a operator-issue not to be dealt with in the > protocol. I suggest dropping this sentence or at last spell > MUST in lower case. > Probably lower case. The point is confidentility is meaningless without authenticaion. > ------------------------------------- > 5.2 > Isn't that a security consideration (and belongs to that secition)? > RFC3552 request the residual risk should be descripted in the security consideration section. The section is about residual risk of generic certificate. > ------------------------------------- > 6.2 > IANA registry names must be suggested (of course this comment > is irrelevant if we drop VERSION). > > ------------------------------------- > Consistent Spelling > Both version and VERSION is used for the respectively-named > field. I suggest to resort to a single spelling. This also > removes some ambiguities if the version field or the concept > of a version is meant in some parts of the text. I suggest > using VERSION consistently for the respective field. > Agreed. > ------------------------------------- > "Security Considerations" is missing > I wonder I didn't spot this earlier. IMHO any document must > have a "Security Considerations" section. Of course, the > whole document talks about security, but does that obsolete > the section showing the weaknesses of the protocol? > Section 5 is Security Consideration, but maybe I should add a S to it (Security Considerations):-) > For example, I have at least three candiates to be included: > > - Problems in relay scenario > A relay may receive data via traditional syslog and forward > it via a tls-encrypted channel to its next destination. In > this case, the channel to the next hop is secured, but the > trust level of the message is considerably lower. > > - there is no rule that a sender must use the same host name > inside the -protocol HOSTNAME field as it uses in the > certificate's common name. I think that has some security > implications. > TLS transport does not check HOSTNAME in syslog message because transport must not depend on content of the payload (or else a relay must check the content of each message). > - cipher suites and such are left to the operator. We should > indicate the (serious) consequences of this selection > > --------------------------------------------- > One note on the cipher suites: > I know there has been some discussion previously, but I > wasn't able to find the post in question in the archive. > Probably you can help me out. > > Question: how do we guarantee a minimum interoperability of > implementations of this document if we do not specify any > cipher suite? > Tom and I discussed this issue on the mailing list. TLS protocol has its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS specification says that if application profile(syslog-tls in this case) does not specify a mandatory cipher suite, TLS mandatory suite will apply. So, no need to specify one in this specification. _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
