Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 2 Nov 2009 18:24:32 +0100

Some additional thoughts:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Wednesday, October 14, 2009 11:24 PM
> To: [email-masked]
> Subject: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt
> 
> I Just posted a -00 version of the syslog DTLS draft
> (http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-00.txt). I
> tried to merge the two proposals together and keep consistent with the
> Syslog TLS draft.  Below are some issues I have identified, I'm sure
> there are others.
> 
> 1. Transport
> 
> DTLS can run over several different transports,  right now the draft
> requires UDP and recommends DCCP.  I think these are the most well
> defined.  The draft also forbids DTLS over TCP and favors TLS over TCP
> to keep things consistent.  I left out SCTP, I'm not sure where SCTP
> over DTLS is in the process and there also is a TLS option for SCTP.

I think we should limit the scope to pure datagram services. Rest as in reply
to Tom.

> 
> 2. Port Number
> 
> DTLS could use the same port and TLS, which seems simple.  The
> difficulty could be that for some transports you could use either TLS
> or
> DTLS (SCTP for example).  In theory you could tell the difference
> between TLS and DTLS by version number so maybe this isn't a problem.

The problem would be resolved if we disallow stream bindings - can we?

> 3. Initiation
> 
> One of the drafts allowed either side to initiate.  I did not include
> this.  If we have a use case for it we could bring it back in.

I thought a bit more about this. I do not see any use case where a
server-side open would be required. 

> 4. Dead Peer Detection
> 
> There has been a lot of discussion on DPD on the list.  I don't have
> any
> specific remedy in the draft, just a warning that it could be a
> problem.
> Its likely that some work on this will happen in DTLS, but I'm not
> confident on the timeframe at this point.

I think the best solution is to simply include a warning and leave the rest
to future DTLS work. Doesn't make sense to (re-)invent that wheel.

> 
> 5. Message Size
> 
> The text on message size could use some review.

commented on that in reply to Tom as well.

I have one more comment to 5.1.2, especially

"If reliability is required, then Syslog over TLS may be used"

This comes with the co-notation that Syslog over TLS is reliable. However, as
no app-level ACKs are used, it is not totally reliable. RFC5425 contains such
a note. I find it important to not create the impression that RFC5425 is a
fully reliable protocol. All too often in practice I work with folks that try
to build an audit-grade syslog system and, often late enough, then find out
the hard way that some message loss can currently not be prevented. This
creates a lot of frustration and wastes many resources.

We have not yet managed to create an audit-grade syslog transport other than
RFC3195. I, too, was an advocate for the simple model RFC5425 utilizes, and
there were good reasons for doing so (all those that seemingly make RFC3195
so far a failure). When we are through with -sign and -dtls, we should
probably look into rechartering for RFC3195bis and/or an extension to RFC5425
to provide the missing bits for reliability, but I think getting -sign and
-DTLS out of the door should have priority.

All in all, I really like the good work Joe has done! I think (and hope) we
do not need too many revisions to create a version that can be published.

Rainer

> 
> Cheers,
> 
> Joe
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of [email-masked]
> Sent: Wednesday, October 14, 2009 1:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Syslog] I-D Action:draft-ietf-syslog-dtls-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Security Issues in Network Event
> Logging Working Group of the IETF.
> 
> 
> 	Title           : Datagram Transport Layer Security (DTLS)
> Transport Mapping for Syslog
> 	Author(s)       : J. Salowey, et al.
> 	Filename        : draft-ietf-syslog-dtls-00.txt
> 	Pages           : 18
> 	Date            : 2009-10-14
> 
> This document describes the transport of syslog messages over DTLS
> (Datagram Transport Level Security).  It provides a secure transport
> for
> syslog messages in cases where a connection-less transport is desired.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 2 Nov 2009 18:27:04 +0100

I thankfully have now also been able to review the document.

> Behalf Of tom.petch
> Sent: Tuesday, October 27, 2009 10:13 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt
> 
> Good stuff.

full ack!

> Ports; I like the idea of a common port, because it makes operational
> deployment (eg filtering in Middle boxes) so much simpler and less
> error prone.

I agree, especially if we intend to prohibit DTLS use over TCP (what I think
is a good idea).

> DTLS has an updated I-D in Working Group Last Call
> draft-ietf-tls-rfc4347-bis
> which I think we should reference.  It covers DTLS over DCCP properly,
> which its predecessor might not be seen to.
> 
> Message size I think needs more coverage.  I would include a summary of
> the
> advice on PMTU discovery in DTLS 4.1.1.1 and specifically mention the
> 2**14
> limit on  records in DTLS.  Earlier discussions on this list showed a
> desire for
> 2**16
> syslog messages which, to me, implies fragmentation by the transport
> sender.

This is a hard issue. I think we should review our use case for DTLS. To me,
the primary driver behind DTLS in a syslog system is the ability to encrypt
messages, while still retaining the ability to send single-frame messages,
which may be the only way to convey any information inside a broken network.
This is properly described in Section 1.

When this is our ultimate goal, we need to preserve that capability. That
means we can not permit fragmentation. While I am always an advocate for
longer message sizes, I do not think that the reasoning behind that fits in
into the DTLS scenario. Larger size messages are almost exclusively seen in
audit-like systems (e.g. IHE), much less in network management. RFC5426
defines a lower limit of 480 octets, which is hard, but fact. It then
recommends 2K and specifies an upper limit of 64K. I think we should follow
that route with a lower limit of 512, recommended 2K (should be well
sufficient for management info) and 16K being the upper bound. As of my
understanding, that should solve the size limit issue without hurting anyone.
The lower limit is higher than in RFC5426, the recommended size is the same,
only the upper limit is lower, but still on the save side for management
information.

As a side-note, it may make sense to spell out - if we agree on that - that
DTLS is NOT a transport to be used for auditing purposes.

> Dead Peer Detection I would sit on until something more happens with
> the
> TLS Working Group.

sounds reasonable.

Rainer Gerhards
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Joseph Salowey (jsalowey)" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, October 14, 2009 10:23 PM
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Nov 2009 06:49:18 -0500

I think including a script to generate certificates and configure
their use would meet this requirement, so I definitely think it is
something that you could do.

I'm not at all convinced that generating a cert if you don't have one would be wrong.
Debian has chosen to do that for a number of applications we ship and it seems to work out well.

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 2 Nov 2009 18:00:52 +0100

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, October 28, 2009 3:22 PM
> To: Eliot Lear
> Cc: David Harrington; 'tom.petch'; 'Joseph Salowey (jsalowey)';
> [email-masked]; 'Wes Hardaker'; 'Juergen Schoenwaelder'; 'Huang Min';
> Rainer Gerhards; 'Sharon Chisholm'; [email-masked]; 'Glenn M. Keeni';
> 'Miao Fuyou'; 'Anton Okmyanskiy (aokmians)'; [email-masked];
> [email-masked]; 'Woundy, Richard'; 'Sumanth
> Channabasappa'; [email-masked]; [email-masked];
> 'Richard Graveman'; 'Ong, Lyndon'; 'Andi Kosich'; 'Sam Hartman';
> 'Margaret Wasserman'; 'Jeffrey Hutzelman'
 
> Why isn't usability sufficient for a MUST in this case?  Here's the
> argument.  Unless turning on security is as easy as not doing so, then
> there is a sigfificant cost to security and we will not get the
> benefits we should.  As a result, especially because there are
> significant passive attacks protected against by using DTLS, the
> security of the protocol will be significantly improved by requiring
> implementations provide a easy-to-enable security solution.
> 
> Generating a self-signed cert on a Mac or Linux box is *not* easy
> compared to running syslogd.
> 
> Sam, with his painless-security.com hat on.

I agree to the argument, but from the technical perspective it is hard to do
this in a typical linux syslogd. The problem is that all "user interface" you
can expect to have is a config file and a text editor. Blindly generating
certificates if they are not specified in the config file is not appropriate,
I think. So the user needs to run an external tool in any case. I fully agree
that openssl is not what we have on our mind when thinking about ease of use.
But any more graphical front end will most probably not be delivered by
default by the distro's package managers. They, for good reason, try to keep
the syslogd footprint to as small as possible. In the end result, a specific
syslogd might support a GUI for certificate generation, but the user will
probably need to run through the process of compiling that functionality from
source, what is also a showstopper for many users.

On the other hand, a small shell script working as a "front end" to openssl
(or whatever) will probably be included in the distro's syslogd (or
syslogd-dtls) package.

For this reason, I would prefer to see a RECOMMENDED, but I definitely would
not object a MUST. However, we need to be aware that there are many parties
involved in making this MUST actually happen, so it will not be much stronger
than a RECOMMENDED in practice.

Rainer