[Syslog] Notes on TLS transport

Eric Rescorla <ekr@networkresonance.com> Mon, 07 August 2006 03:37 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9vvy-0004e8-Uj; Sun, 06 Aug 2006 23:37:42 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9vvx-0004dz-2o for syslog@ietf.org; Sun, 06 Aug 2006 23:37:41 -0400
Received: from laser.networkresonance.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9vvw-0006GW-Ac for syslog@ietf.org; Sun, 06 Aug 2006 23:37:41 -0400
Received: from networkresonance.com (raman.networkresonance.com []) by laser.networkresonance.com (Postfix) with ESMTP id 13121222425 for <syslog@ietf.org>; Sun, 6 Aug 2006 20:45:41 -0700 (PDT)
To: syslog@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Sun, 06 Aug 2006 20:37:39 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060807034541.13121222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Subject: [Syslog] Notes on TLS transport
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org

I just finished reading:

Comments below.

It seems like it would be nice to have a consistent approach
to the generic question of who is the TLS client and who is the TLS
server and client.  The TLS draft specifies that the receiver is the
TLS server but the DTLS draft can work either way. As I understand
draft-petch-gerhards-syslog-transport-dtls, the argument for allowing
the sender to be the server is:

    (a) authentication for the sender is what's important.
    (b) concerns about performance on the syslog device/sender

I don't think (b) turns into an argument for reversing the
client/server roles. The expensive step is the RSA signature
or decryption and that needs to be performed by the authenticating
party. Moreover, it's really not *that* expensive. I would
expect it to take a second or so on all but the lowest
power devices--though there used to be reports that the Dragonball
processors in palms had particularly bad bignum performance.

My suggestion would be to stick with standard TLS practice here and
have the sender be the server. Having the server have a certificate
isn't that big an obstacle, especially if it's self-signed.

S 3.1:

   report errors.  Then, there is an ongoing layered record protocol
   that handles encryption, compression, and reassembly for the

I would say, "encryption and message integrity" rather than 
"encryption, compression, and reassembly"

S 3.2:
   Confidentiality is provided using symmetric cryptography for data
   encryption.  TLS supports both stream cipher and block cipher.  The
   key for encryption is derived from a secret established by the
   handshake protocol.  The secret is kept private even if there is an
   eavesdropper in the middle.

This only obtains if at least one sid ie authenticated.

   Integrity is provided by using HMAC [6] (computed with a secure hash
   function) to check the integrity of a message.  Modification without
   the appropriate key is detectable.

I would just say "a Message Authentication Code (MAC)". Future
versions of TLS may not use HMAC.

   Authentication is provided by a handshake protocol.  The peer's
   identity is authenticated using a certificate and signature, based on
   asymmetric cryptography.

TLS server auth is often done by proving possession of the private
exponent by doing an RSA decryption rather than a signature. TLS
client auth is typically with a signature.

S 5.2:
   TLS uses certificate [5] to authenticate the peers.  When a sender
   authenticates a receiver it MUST validate the certificate.  It SHOULD
   check the common name(CN) of the certificate against the host name of
   the receiver if it has knowledge of a common name/host name mapping.
   If the common name does not match the host name, the sender SHOULD
   send an "access_denied" error alert using the TLS alert protocol to
   terminate the handshake, and then it SHOULD close the connection.

Do you want to cite RFC 2818 here?

Also, some clarity about whether the sender is expected to validate
the receiver's cert would be helpful. Similarly, is sender auth

   another active session when a new session is requested, in order to
   save the expense of another TLS handshake.  The security parameters
   of the resumed session are reused for the requested session.  The
   certificate MUST be checked when resuming a session.  If the resumed
   session and current session use different certificates, resumption
   MUST not happen.  The security parameters SHOULD be checked against
   security requirement of requested session to make sure the resumed
   session provides proper security.

Resumed sessions do not involve a certificate exchange, so there's
no way the certificate could be different. Similarly, the security
parameters are always the same.

S 5.3:
   All Syslog messages MUST be sent as TLS "application data".  There
   MAY be multiple Syslog message in the same TLS record.  The
   application data is defined with the following ABNF [3] expression:

TLS's abstraction is as a stream, so this isn't really the business
of htis spec.

S 6.1:
   TLS authentication and the establishment of secrets is based on
   certificates and asymmetric cryptography.  This makes TLS transport
   much more expensive than UDP transport.  An attacker may initialize
   many TLS connections to a receiver as a denial of service attack.
   Since a receiver may act upon received data, for Syslog over TLS, 
   the receiver SHOULD authenticate the sender to ensure that 
   information received is authentic.

TLS is more expensive than non-TLS. The issue of TCP vs. UDP is kind
of orthogonal.

S 6.2:

   When a certificate is issued to a class of device or application, the
   certificate may be shared by multiple hosts.  Multiple hosts know the
   private key of the certificate. When the certificate in one host is
   compromised, then the certificate for all hosts that share the
   certificate is compromised. Any communication that is bound to the
   certificate is at risk.

It depends what you mean "at risk". Say you have two clients who
share the same cert. If client A is compromised, then the attacker
can impersonate client B, but it can't view data on or tamper
with a channel that client B actually established. The situation
is a bit more complicated for servers and depends on which cipher
suite you're using (PFS of not).

S 6.3:
   Different applications in the same host may have different security
   levels (e.g., the kernel may have higher a security level than a
   document editor application). If a requested session resumes an
   existing session, then the requesting application can decrypt the
   Syslog messages of the resumed session using same cipher parameters
   as defined for the resumed session. When a session is being resumed
   from an application with a different security level, care must be
   taken to avoid disclosing sensitive data to an unauthorized
   application.  A sensitive session must not be resumable.

This isn't clear to me. It depends a lot on how the keying material
is handled. You need to explain the threat model a lot more 
clearly here..

S 1.4:

   connections - which may not be suitable for the application; DTLS
   offers the option of TLS over UDP, adding reliability to UDP but
   without all the additional features that TCP brings.  As such, it
   offers an attractive security option for UDP-based applications.

Reliability is added *only* for the handshake, not data transport.

S 1.6:
   Most applications which now run over TLS were previously running over
   TCP and as such already had an application level dialog.  In order to
   invoke TLS, these applications could then change their start command
   (eg STARTTLS) or, having established a TCP connection, invoke TLS (eg
   AUTH) to make the connection secure.

I'm not sure I agree with this characterization. E.g., neither
HTTP [2818] nor SIP [3261] behaves this way. You just have a
separate port.

S 2.1:
   A consequence of this mapping, of DTLS client to syslog server, is
   that where certificates are used for server authentication, then the
   syslog server is the one that has to verify the syslog client's
   certificates (something that it is likely to have the greater
   resources to do).  The syslog client must have a certificate; the
   syslog server certificate remains optional.

Cert verification is actually fast. It's being the authenticating
party that's slow.

S 2.8:
This probably isn't necessary.


Syslog mailing list