Hi Joe, this sound quite reasonable, especially the "dedicated port" argument is a good one. And, of course, if the -transport-tls connection fails, a local syslog sender may still be configured to fall back to some other mode (e.g RFC 3195 or RFC 3164). It just isn't then using -transport-tls.
However, I think this "MUST fail" should be explicitly spelled out in the draft. Otherwise we have some confusion. The issue arose from this conversation with Martin: http://mail-index.netbsd.org/tech-userlevel/2008/05/06/msg000553.html I remember similar discussions when implementing RFC 3195 and they lead to interop problems between different implementations (namely SDSC syslogd vs. liblogging vs. Cisco IOS). In that case, there was a somewhat unclear definition about the session closure (which stems back to RFC 3080 and is not a 3195 issue). Would like to prevent this for -transport-tls if at all possible. OF course, we won't catch anything, but now that we begin implement (and still have a draft and not a final RFC), we should feedback experience into the draft. At least this is my humble POV. Rainer > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 06, 2008 11:56 PM > To: Rainer Gerhards; [email protected] > Subject: RE: [Syslog] -transport-tls, section 4.2 > > Since Syslog TLS is taking the approach of a separate TCP port for TLS > I > think it would be more appropriate to reject the connection instead of > falling back to insecure. I am inclined to say that if the handshake > fails the connection MUST be terminated. If the client wants an > insecure session they can connect to the insecure port. > > Joe > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > > Sent: Tuesday, May 06, 2008 5:38 AM > > To: [email protected] > > Subject: [Syslog] -transport-tls, section 4.2 > > > > Hi there, > > > > I have today released a basic version of rsyslog with an > > experimental first -transport-tls implementation > > (announcement at http://www.rsyslog.com/Article222.phtml ). I > > am now digging deeper and refining the implementation. I try > > to convey some thoughts and ask some questions along this > > route - in the hopes to gather some feedback. > > > > The initial feedback is that it is quite trivial to implement > > -transport-tls - just as anticipated. But I think it is good > > to see it works out in practice. > > > > My first question is on section 4.2. It does not tell what to > > do if the TLS handshake fails. One can argue that the second > > sentence implies that the connection should be dropped on > > handshake failure. However, this is not explicitly stated. It > > may be desirable to continue without TLS in that case. > > > > When GSSAPI support was implemented in rsyslog, there was a > > strong community demand for such a fallback mode. Thus, if > > the GSSAPI handshake fails, and rsyslog is configured > > accordingly, it falls back to plain TCP syslog (unencrypted). > > I know this is dangerous, as a man in the middle may force > > unencrypted transfer in this case. But provided it is an > > operator-selectable option (and by default off), I think it > > is an acceptable risk. > > > > Question now: how to handle this in spite of -transport-tls? > > With the current text, would my application compliant to it > > if it permits to run without TLS support when the handshake > > fails (in that case obviously not complying to any standard)? > > > > I would suggest that this case is being at least mentioned. I > > would also like to hear some opinions on this topic. > > > > Thanks, > > Rainer > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
