Hi Miao, <inline>
Rainer > -----Original Message----- > From: Miao Fuyou [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 23, 2006 3:38 AM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: RE: [Syslog] Updated Syslog-tls Document > > 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. > Interesting. I am using http://www.apps.ietf.org/abnf.html. I will also try the one you used and do an additional verification on -protocol with it. However, I still find that %d32 is more precise than " " and I also have the impression that RFC 4234 recommends that form (but I may be wrong). Bottom line: I am more happy with %d32 (or %x20 as I think all others are in hex in the doc). > > ------------------------------------- > > 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. Well... maybe it is just a wording issue. Are we actually REQUIREING a sender to authenticate the receiver in all cases? If so, we should state that. My impression so far is that this is something that is optional and at the discretion of the sender or the operator configuring it. If so, we should state that clearly too. As an implementor, I am unsure what to do if I use the above text as a guideline. > > > ------------------------------------- > > 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. > see below... > > ------------------------------------- > > 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):-) (also on 5.2) - I must have been blind. I've gone several time through the document and always overlooked the title of section 5. I am not sure if the additional "s" had helped my ignorance ;) So I think you can disregard my comment. > > > 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). wouldn't it still be useful to put that information into the security considerations? Would it be useful to add something to the security considerations of -protocol (on the lines of "if the transport provides identification of the sender, a receiver MAY / SHOULD verify the provided HOSTNAME)"? WG comment appreciated. > > > - 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. Ahh... that was the message I did not find in the archive. Thanks for bringing it up again. That obiously solves the interop problem. However, I am still of the view that we should advise operators to use strong suites in the security considerations section. _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
