Re: [secdir] FW: secdir review of draft-ietf-syslog-dtls-05

[Chris Lonvick <[e-mail]>]

Hi Steve,

I appreciate your review and apologize for the delay in responding.

Comments in-line.

On Wed, 9 Jun 2010, Stephen Hanna wrote:
>
>
> -----Original Message-----
> From: Stephen Hanna [mailto:[e-mail]]
> Sent: Monday, May 17, 2010 6:13 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: secdir review of draft-ietf-syslog-dtls-05
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other comments.
>
> This document defines a DTLS transport for syslog. The document is
> well-written, clear, and seems to serve a worthwhile purpose.
>
> Although the security considerations section is brief (mainly just
> referring to the security considerations in RFC 5425, RFC 5246,
> and RFC 4347), it is largely adequate. I see only one omission.
>
> One difference between the security considerations for syslog over
> DTLS and those for syslog over TLS (unnoted in the current Security
> Considerations section) is that DTLS does not provide retransmission.
> If an attacker can cause a packet to be dropped (especially one
> carrying significant information about an attack), the transport
> receiver may not consider this a significant event and so the syslog
> server may be completely unaware of the occurrence. This contrasts
> with syslog over TLS where a dropped packet would be retransmitted
> until acknowledged or until the TLS connection goes down (indicating
> to the transport sender and receiver and perhaps to the syslog client
> and server that a significant event has occurred). Maybe it would be
> a good idea to recommend that the transport receiver notice gaps in
> the DTLS sequence numbers and notify the syslog server. Still, this
> is not as good from a security standpoint as syslog over TLS since
> none of the client code will be aware that the dropped message was
> not received. At least, there should be a discussion of this issue
> in the Security Considerations section of this document.

It's discussed in section 5.4 (Unreliable Delivery - in the Security 
Considerations section) in RFC 5426 and throughout Section 3.1 
(Loss-Insensitive Messaging) in RFC 4347.  I'm thinking that it would be 
good to note this in Section 4 (Using DTLS to Secure Syslog) in the draft.

Overall, the community is comfortable with the loss of information as 
they've been using syslog/udp for many years and know the problems with 
that.  RFC 5424 also notes that implementers who wish a lossless stream 
should be using tls/tcp as their transport.  From that, it's probably best 
to reference RFC 5848 (referenced as draft-ietf-syslog-sign in the draft) 
which can also provide an indication of loss of messages.


>
> In addition to this concern, I have noticed a few areas that could
> use some clarification and maybe some fixes.
>
> Section 5.3 says "Implementations MUST support the denial of service
> countermeasures defined by DTLS." That's good but it's not clear
> whether this means that these countermeasures MUST always be enabled.
> Since that is not explicitly stated, it seems that a server could
> have those countermeasures enabled by default and a client could
> have them disabled by default. That would result in a client and
> server that would not interoperate until the administrator tracked
> down the problem and changed their configuration. I suggest that
> the document be changed to require not only that implementations
> support these countermeasures but that they be enabled by default.

Good catch.

>
> Section 7 says "The security policies for syslog over DTLS are the
> same as those described in [RFC5425]." Does that mean that all the
> normative text in section 5 of RFC 5425 applies to implementations
> of this document as well? I hope so but if that's the intent, it
> should be explicitly stated (for example by adding the text "and
> all the normative requirements of section 5 of [RFC5425] apply").

That is the intent and the added text looks good.

>
> Once these issues are addressed, I'm sure that the document will
> be a worthwhile and relatively secure addition to the RFC series.
> Congratulations and thanks to the editors/authors for their work.

I'm going to open these as issues for the authors to address.  We have 
several other open issues resulting from other LC reviews and IESG 
COMMENTS and DISUCSSes which we will resolve in a new ID.

Best regards,
Chris