Hi Miao, thanks for the update. I have gone through the draft again and found some, mostly minor, issue. I have listed them below:
------------------------------------- 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. ------------------------------------- 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 ------------------------------------- 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. ------------------------------------- 5.2 Isn't that a security consideration (and belongs to that secition)? ------------------------------------- 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. ------------------------------------- "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? 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. - 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? --------------------------------------------- Rainer > -----Original Message----- > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 22, 2006 2:13 AM > To: [EMAIL PROTECTED] > Subject: [Syslog] Updated Syslog-tls Document > > Hi, > > There are two major changes since last update. > 1, Section 3 is removed. It is an introductory text on TLS, > and is neccesary > because TLS is already a normative reference. > 2, Updated the section 4.3.2 (original 5.3.2), removed the > text about TLS > layer alert to signal a syslog-transport event > > Regards > Miao > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
