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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 14 Oct 2009 14:23:34 -0700

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.  

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.  

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.  

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. 

5. Message Size

The text on message size could use some review. 

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: "tom.petch" <[email-masked]>
Date: Tue, 27 Oct 2009 10:12:37 +0100

Good stuff.

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.

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.

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

Tom Petch

----- Original Message -----
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 14, 2009 10:23 PM
Subject: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt

1. Transport

2. Port Number

3. Initiation

4. Dead Peer Detection

5. Message Size

Cheers,

Joe

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Oct 2009 18:14:40 -0400

Thanks Tom.

We need others in the WG to review this draft as well.

We have committed to submitting this to IESG by March, and we have
holiday seasons (Xmas, Chinese New Year, etc.) that are likely to get
in the way. So we really need to get in-depth reviews done soon so we
can get issues resolved and revisions published within the next four
months.

Please help by reviewing this document.

Thanks
David Harrington
[email-masked]
syslog WG co-chair

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Tuesday, October 27, 2009 5:13 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Syslog] FW: I-D Action:draft-ietf-syslog-dtls-00.txt
> 
> Good stuff.
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Oct 2009 13:10:28 +0100

David,

Thank you for bringing this draft (back) to my attention.  I want to 
congratulate the authors on a generally well written document.  DTLS is 
an important missing component from the SYSLOG framework.  I agree 110% 
with the introduction, and perhaps would go further, that sometimes in 
the worst of circumstances, it is important simply to try to get the 
message out and hope someone hears it.  What you will find from me below 
are suggestions to simplify some text, most of which is non-normative.

I believe Section 5.1 is serving two masters, and in my experience, this 
generally doesn't work well.  Your first master is rationale behind 
choice of transport.  What you are reaching for here is a protocol 
applicability statement.  If you have the discussion about protocol 
applicability, and nothing says that you even need to go there at this 
stage, my suggestion would be to include it in your introduction and do 
away with all of the sub-sub-headings in Section 5.1.

By way of example, I believe you are striving for relatively simple 
statements a'la this:
> In those circumstances where reliability or ordering is important, 
> SYSLOG over TLS is appropriate.  As the Internet best runs on the 
> basis of appropriate resource sharing, SYSLOG over DTLS over DCCP is 
> defined in this document.  For systems where DCCP is either not 
> available or not usable (such as the afformentioned situation), DTLS 
> over UDP is also defined.

Editorial:

s/has state such problems/has discussed (or addressed) this problem

Section 5.3:

1st para, 2nd sentence:

Why only RECOMMENDED?

2nd para, last sentence:
> This document is assumed to apply to
>    future versions of DTLS, in which case the mandatory to implement
>    cipher suite for the implemented version MUST be supported.

Why do you need to say this at all?

3rd paragraph:

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

Why is this necessary?  Isn't it sufficient to import and make use of a 
self-signed certificate?  Isn't it easy enough to run OpenSSL on a Mac 
or linux box and import the stuff?  I could see an argument for 
usability concerns, but that's not sufficient grounds for a MUST.

An aside about your 2119 language: I haven't reviewed all of it, nor am 
I an 2119 expert, but I can say that you will confuse people when you 
use MUST, SHALL, and REQUIRED.

Section 5.3.2, 2nd para, last sentence:

> The security parameters SHOULD be checked against the
>    security requirements of the requested session to make sure that the
>    resumed session provides proper security.

I think what you are aiming at here is a downgrade attack.  First, isn't 
this covered in DTLS?  Otherwise, here I would argue for a MUST, and I 
would be more clear about what you are protecting against, such as the 
following:

> In order to avoid downgrade attacks, an exiting session MUST NOT be 
> reused if its protection does not match the minimum policy 
> requirements of the new SYSLOG over DTLS session request.
Editorial:

Same section ABNF: is it not customary to use lower case, particularly 
for non-terminals?

Again, thanks to the authors for putting this out there.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Oct 2009 10:21:31 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Why is this necessary?  Isn't it sufficient to import and
    Eliot> make use of a self-signed certificate?  Isn't it easy
    Eliot> enough to run OpenSSL on a Mac or linux box and import the
    Eliot> stuff?  I could see an argument for usability concerns, but
    Eliot> that's not sufficient grounds for a MUST.

    Eliot> An aside about your 2119 language: I haven't reviewed all
    Eliot> of it, nor am I an 2119 expert, but I can say that you will
    Eliot> confuse people when you use MUST, SHALL, and REQUIRED.

    Eliot> Section 5.3.2, 2nd para, last sentence:

    >> The security parameters SHOULD be checked against the security
    >> requirements of the requested session to make sure that the

    Eliot> I think what you are aiming at here is a downgrade attack.
    Eliot> First, isn't this covered in DTLS?  Otherwise, here I would
    Eliot> argue for a MUST, and I would be more clear about what you
    Eliot> are protecting against, such as the following:

    >> In order to avoid downgrade attacks, an exiting session MUST
    >> NOT be reused if its protection does not match the minimum
    >> policy requirements of the new SYSLOG over DTLS session
    >> request.
    Eliot> Editorial:

    Eliot> Same section ABNF: is it not customary to use lower case,
    Eliot> particularly for non-terminals?

    Eliot> Again, thanks to the authors for putting this out there.

    Eliot> Eliot

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.