Subject: [Syslog] -transport-tls, section 4.2

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 6 May 2008 14:37:50 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/syslog

---

From: Martin Schütte <[email-masked]>
Date: Tue, 06 May 2008 23:38:09 +0200

> not explicitly stated. It may be desirable to continue without TLS in

IMHO the only important point is that a client explicitly configured to 
use TLS will only send data to an authenticated server, thus it has to 
abort if the handshake fails.

One cannot specify much more, because there are too many possible 
policies a sysadmin might want to configure; ranging from TLS without 
client/server-certificates up to his own CA or a predefined list of 
valid client/server certificates.
So it should be left to the implementation to offer different operation 
modes, for example 'UDP', 'TLS if available', and 'TLS'.

Then as a user I might expect a mode 'TLS if available' to continue in 
TCP or UDP after a failed handshake, while with 'TLS' I have to rely on 
an abort.

-- 
Martin

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 6 May 2008 14:56:25 -0700

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-masked] 
> [mailto:[email-masked]] On Behalf Of Rainer Gerhards
> Sent: Tuesday, May 06, 2008 5:38 AM
> To: [email-masked]
> 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.
> 
> -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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 7 May 2008 11:04:53 +0200

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

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Tuesday, May 06, 2008 11:56 PM
> To: Rainer Gerhards; [email-masked]
> Subject: RE: [Syslog] -transport-tls, section 4.2
>