[Syslog] -transport-tls, section 4.2

"Rainer Gerhards" <rgerhards@hq.adiscon.com> Tue, 06 May 2008 12:38 UTC

Return-Path: <syslog-bounces@ietf.org>
X-Original-To: syslog-archive@megatron.ietf.org
Delivered-To: ietfarch-syslog-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A043A6C59; Tue, 6 May 2008 05:38:32 -0700 (PDT)
X-Original-To: syslog@core3.amsl.com
Delivered-To: syslog@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37733A6E40 for <syslog@core3.amsl.com>; Tue, 6 May 2008 05:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSfBq-m3C-IM for <syslog@core3.amsl.com>; Tue, 6 May 2008 05:38:24 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 533D628C3E8 for <syslog@ietf.org>; Tue, 6 May 2008 05:37:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 3B7A17AE5E5 for <syslog@ietf.org>; Tue, 6 May 2008 14:34:45 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AavUH5uNTJjR for <syslog@ietf.org>; Tue, 6 May 2008 14:34:45 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id 055877AE5E1 for <syslog@ietf.org>; Tue, 6 May 2008 14:34:44 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 06 May 2008 14:37:50 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308F62@grfint2.intern.adiscon.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: -transport-tls, section 4.2
Thread-Index: Acivdf76lZhV7DgWQq6X0iut3++4HA==
From: Rainer Gerhards <rgerhards@hq.adiscon.com>
To: syslog@ietf.org
Subject: [Syslog] -transport-tls, section 4.2
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

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