RE: [Syslog] Notes on TLS transport

Miao Fuyou <> Mon, 07 August 2006 12:45 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GA4Tz-0003iO-Me; Mon, 07 Aug 2006 08:45:23 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GA4Ty-0003h3-32 for; Mon, 07 Aug 2006 08:45:22 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GA1j7-0003Nn-Nn for; Mon, 07 Aug 2006 05:48:49 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GA1fR-0005n5-A2 for; Mon, 07 Aug 2006 05:45:02 -0400
Received: from (szxga03-in []) by (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <> for; Mon, 07 Aug 2006 17:47:11 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <> for; Mon, 07 Aug 2006 17:47:10 +0800 (CST)
Received: from m19684 ([]) by (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <> for; Mon, 07 Aug 2006 17:48:50 +0800 (CST)
Date: Mon, 07 Aug 2006 17:36:56 +0800
From: Miao Fuyou <>
Subject: RE: [Syslog] Notes on TLS transport
In-reply-to: <>
To: 'Eric Rescorla' <>,
Message-id: <008c01c6ba05$069ea1a0$>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Aca50utioaRZSX13SC6e3n4933UtuwAKqUuA
X-Spam-Score: -2.3 (--)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Response inline, thanks! 

> -----Original Message-----
> From: Eric Rescorla [] 
> Sent: Monday, August 07, 2006 11:38 AM
> To:
> Subject: [Syslog] Notes on TLS transport
> S 5.2:
>    TLS uses certificate [5] to authenticate the peers.  When a sender
>    authenticates a receiver it MUST validate the certificate. 
>    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
> required?

A very brief clarification about server authentication is in section 6.1
(last sentence). Sender authentication is preferrable when DoS is a concern,
an unauthenticated sender may send spurios spurios Syslog messages to
receiver. But, the threat model in this document explicitly excludes denial
of service. 

> 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).

Thanks, very good clarification. I will update the text. BTW, generic
certificate are only issued to senders, server would not be issued a generic

> 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..

Yes. there is problem for this text.  I checked 4346bits, ClientHello.Random
and ServerHello.Random is used in 4346bis to make encryption key and MAC
secrets different for resumed sessions. So, I may drop this paragraphy from
this document.

Syslog mailing list