Subject: [Syslog] js review of draft-ietf-syslog-dtls-01.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Feb 2010 17:54:48 +0100

Hi,

Chris Lonvick asked me to review draft-ietf-syslog-dtls-01 and here
are my comments. I believe the document is not yet ready for the IESG
and needs at least one update to improve on a number of details. For
sake of simplicity, I will quote the relevant part of the ID and then
comment it.

   The datagram transport layer security protocol (DTLS) [RFC4347] is
   designed to meet the requirements of applications that need secure
   datagram transport, by combining UDP transport with TLS security.
   DTLS has been mapped onto different transports (i.e.  UDP [RFC0768]
   and DCCP [RFC4340] ), to secure syslog in more situations.

I think ", to secure syslog in more situations" serves no value here.

   important, SYSLOG over TLS is appropriate.  Syslog over TLS does not
   provide application layer acknowledgements and therefore is not a
   fully reliable solution.

I do not understand why the last sentence is here. The purpose of this
document should be to define SYSLOG over DTLS and not to discuss the
properties of other SYSLOG transports.

   The term "connection" used in this document is used to refer to a
   secure association between transport sender and transport receiver
   that permits the transmission of one or more SYSLOG messages within
   the lifetime of the connection.

Do we need this term "connection"? There is a potential for confusion,
e.g. the abstract talks about "connection-less transport" and hence
there are multiple meanings of "connection" in place. If we need the
term, we should perhaps call it a "DTLS connection" and make sure we
use the full term everywhere. Also "secure association between
transport sender and transport receiver" can be anything secure, not
particularly DTLS - was that the intention?

   Syslog messages are secured in a hop-by-hop manner.  The security
   requirements for Syslog are discussed in [RFC5425].

I believe this is not quite right. Signed SYSLOG messages seem to
provide end-to-end authentication, contradicting the first sentence.
My reading of Section 3 of RFC 5425 (you might want to be explicit) is
that it talks primarily about requirements for secure SYSLOG
transports and not SYSLOG per se.

   TLS typically uses certificates [RFC5280] to authenticate peers.

I am not sure why this sentence is there. I suggest to remove it.

 5.3.1.  Certificate-Based Authentication

I suggest to either drop this headline or make this 5.4 instead of
5.3.1, flattening the structure of the document. But I have no strong
opinion about this. OK, I just figured out it this document is
following the structure of RFC 5425. Perhaps should should be
mentioned somewhere explicitly (if that is a reasonable organization,
which could also be discussed).

   Both transport receiver and transport sender implementations MUST
   provide means to generate a key pair and self-signed certificate in
   the case that a key pair and certificate are not available through
   another mechanism.

I do not know the idea behind this requirement is or how I comply to
it. Is this expressing a requirement for the management interface of
the box? Or is the idea that this is used in some automated fashion
(which likely does not make sense but would be harmful if read this
way).

   The transport receiver and transport sender SHOULD provide mechanisms
   to record the end-entity certificate for the purpose of correlating
   it with the sent or received data.

What is an end-entity certificate? And how do I correlate sent or
received data?

   The message length is the octet count of the SYSLOG-MSG in the
   SYSLOG-FRAME.  A transport receiver MUST use the message length to
   delimit a syslog message.  There is no upper limit for a message
   length per se.  As stated in [RFC4347], each DTLS record must fit
   within a single DTLS datagram.  When mapping onto different
   transports, DTLS has different record size limitations.  The
   application implementer SHOULD determine the maximum record size
   allowed by DTLS protocol running over the transport in use.  The
   message size SHOULD NOT exceed the DTLS maximum record size
   limitation of 2^14 bytes.

The text in 5.4 said the following:

   [...] It is
   possible that multiple syslog messages be contained in one DTLS
   record, or that a syslog message be transferred in multiple DTLS
   records.

This seems to be contradictory. If I can fragment a syslog message
over multiple DTLS records, why should a message not exceed the DTLS
maximum record size? So do we do fragmentation / reassembly of syslog
messages, yes or no? If yes, perhaps some text should be added
discussing the implications (delivery of DTLS records is not
reliable).

   [...] Once the transport receiver gets a close_notify from the
   transport sender, it MUST reply with a close_notify.

Is it our job to define this? Does DTLS not specify how to handle
such DTLS alerts?

   Syslog applications SHOULD be implemented in a manner that permits
   administrators, as a matter of local policy, to select the
   cryptographic level and authentication options they desire.  

What is "cryptographic level"? If this refers to the selection of
crypto algorithms, isn't this implementation SHOULD generally true for
crypto protocols and isn't DTLS designed to do this? Is it needed to
spell this out here?

   [...] An
   exiting DTLS session MUST NOT be reused if its protection does not
   match the minimum policy requirements of the new SYSLOG over DTLS
   session request.

I am not sure what "reuse" means here. Some more explanation is needed
to understand this concept of reuse.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>