Subject: [Syslog] New Version: draft-ietf-syslog-dtls-02

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Mar 2010 09:49:18 -0800

I just submitted draft -02 of draft-ietf-syslog-dtls.  Thanks to all the
folks that submitted comments on the draft, I think I have incorporated
them into the latest revision.  Here is a summary of the changes:

1. Reworked the introduction with helpful suggestions from Chris
Lonvick.
2. Removed the definition of connection and made sure when the term is
used it refers to a "DTLS connection"
3. Cleaned up text about security requirements
4. Cleaned up text in section 5.1
5. Removed some extraneous text from section 5.3
6. Added certificate fingerprint as an example of what can be stored to
help correlate identity with sent and received data.
7. Fixed text on message size
8. Removed section on "Cryptographic level" because it was confusing and
did not add anything. 
9. Changed SYSLOG and Syslog to syslog where appropriate.  

I think the draft is ready to go to the IESG.  

Thanks,

Joe

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 5 Mar 2010 15:00:16 -0800 (PST)

Hi,

I want to thank everyone who provided WGLC reviews and comments.  These 
help a lot to keep this process going.  (..and we got our draft in before 
the cutoff date. :)

I've looked over these changes and feel that they address the WGLC 
comments that were received.  I'd appreciate it if the people who did the 
reviews would also do a check.  As everyone has noticed, this document is 
closely following RFC 5425 and I'd like to keep that format.

David has written up a preliminary shepherding document.  I'll edit that 
and send a copy around to the WG before submitting it to the IESG sometime 
next week.

Many thanks,
Chris

On Fri, 5 Mar 2010, Joseph Salowey (jsalowey) wrote:

> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog
>

---

From: Richard Graveman <[email-masked]>
Date: Fri, 5 Mar 2010 18:36:57 -0500

Chis,

> I've looked over these changes and feel that they address the WGLC comments
> that were received.

I strongly disagree on several counts. First, the new document says:

   Transmission of syslog Messages over UDP [RFC5426] defines how to
   provide unreliable, non-secure datagram transport for syslog.  This
   transport is NOT RECOMMENDED.

NOT RECOMMENDED means SHOULD NOT implement. SHOULD NOT implement means
DEPRECATED. There was no WG discussion of deprecating RFC 5426.

In fact, in some cases, protocol security may not be needed, for a
variety of reasons. In other cases, security may already be provided
by, say, IPsec, required in IPv6.

Saying that the work completed just last year is deprecated without
any WG discussion is absurd.

Rich Graveman

---

From: Richard Graveman <[email-masked]>
Date: Fri, 5 Mar 2010 18:50:47 -0500

> that were received.  I'd appreciate it if the people who did the reviews
> would also do a check.

The draft uses RFC 4347 as an essential component. RFC 5746 says:

   This extension also can be used with Datagram TLS (DTLS) [RFC4347].
   Although, for editorial simplicity, this document refers to TLS, all
   requirements in this document apply equally to DTLS.

Because the need for the extensions in 5746 are somewhat application
dependent, this application needs to say "use 5746" or "5746 does not
apply for the following reasons ... ".

Rich Graveman

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Mar 2010 01:07:31 +0100

> any WG discussion is absurd.

I also do not see why this document should make any statements
concerning other transports. I still find the Introduction somewhat
confusing to read. Here is an attempt to rewrite it and shorten it:

--8<--

1.  Introduction

   The syslog protocol [RFC5424] is designed to run over different
   transports.  This document defines the transport of syslog messages
   over the datagram transport layer security protocol (DTLS)
   [RFC4347].

   The DTLS transport is designed to meet the requirements of
   deployments that need a secure datagram-based transport.  DTLS has
   been mapped onto different transport layer protocols, including UDP
   [RFC0768] and DCCP [RFC4340]. This memo defines both options,
   namely syslog over DTLS over UDP and syslog over DTLS over DCCP.
   The syslog over DTLS over DCCP option is recommended over the
   syslog over DTLS over UDP option in deployments where adequate
   resource sharing and congestion control is required.

--8<--

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Mar 2010 16:18:02 -0800

> -----Original Message-----
> From: Richard Graveman [mailto:[email-masked]]
> Sent: Friday, March 05, 2010 3:51 PM
> To: Chris Lonvick (clonvick)
> Cc: Joseph Salowey (jsalowey); [email-masked]
> Subject: Re: [Syslog] New Version: draft-ietf-syslog-dtls-02
> 
> comments
[Joe] Good point, I think we should say renegotiation is not allowed and 5746 does not apply.  If we want to allow renegotiation then we need to include some warnings about renegotiation and say use 5746.   I do not think renegotiation is necessarily required for syslog.

---

From: Richard Graveman <[email-masked]>
Date: Fri, 5 Mar 2010 19:21:45 -0500

> that were received.  I'd appreciate it if the people who did the reviews

Requiring certificates is a lot of extra baggage for worsened
security. All the commonly encountered certificates today are based on
signatures of weak hash functions, primarily SHA-1. Cipher suites
like:

0x00,0xA8     TLS_PSK_WITH_AES_128_GCM_SHA256          [RFC5487]
0x00,0xA9     TLS_PSK_WITH_AES_256_GCM_SHA384          [RFC5487]

do not suffer from the twin disease of weak and inefficient security
and ought to be an option, as Tschonfig and Eronen say in 4279:

      ... pre-shared keys may be more convenient from a key
      management point of view.  For instance, in closed environments
      where the connections are mostly configured manually in advance,
      it may be easier to configure a PSK than to use certificates.
      Another case is when the parties already have a mechanism for
      setting up a shared secret key, and that mechanism could be used
      to "bootstrap" a key for authenticating a TLS connection.

This is precisely the environment is which I would expect to find a
lot of syslog, as opposed to "TLS on the Web."

Rich Graveman

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 5 Mar 2010 16:48:01 -0800

The syslog over TLS document allows for certificates using full path validation and certificate fingerprint matching.  The DTLS document takes the same approach.  This may not fully address your SHA-1 concern, but it does provide a mechanism to get things up and running without a full PKI.  

Also, the GCM cipher suites are not available in DTLS until we complete DTLS 1.2.  Other PSK cipher suites could be implemented with DTLS and syslog, the current draft does not restrict them.  

Joe 

> Sent: Friday, March 05, 2010 4:22 PM

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 7 Mar 2010 07:03:15 -0800 (PST)

Hi Rich,

Yeah; we got a little overzealous on that.  Let's try this:

    Transmission of syslog Messages over UDP [RFC5426] defines how to
    provide unreliable, non-secure datagram transport for syslog.  This
    transport should only be used as described in Section 4.3 of [RFC5426].

Thanks,
Chris

---

From: Richard Graveman <[email-masked]>
Date: Sun, 7 Mar 2010 13:17:49 -0500

Thanks, Chris.

That work.

Rich

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 8 Mar 2010 10:49:51 -0800 (PST)

Hi Rich,

I appreciate the review.

RFC 4279 also says:
=====
    The ciphersuites defined in this document are intended for a rather
    limited set of applications, usually involving only a very small
    number of clients and servers.  Even in such environments, other
    alternatives may be more appropriate.

    If the main goal is to avoid Public-Key Infrastructures (PKIs),
    another possibility worth considering is using self-signed
    certificates with public key fingerprints.  Instead of manually
    configuring a shared secret in, for instance, some configuration
    file, a fingerprint (hash) of the other party's public key (or
    certificate) could be placed there instead.
=====
This is why we have the parts in there about "MUST be able to generate a 
self-signed cert" (identical language to RFC 5425), and the use of 
fingerprints (reference back to 5425).

I understand what you're saying about SHA-1, however I don't think that 
will be an issue since the signature on the certificate is not even 
verified if you use fingerprints.  I'll also back up and say that I havn't 
seen the IESG give specific guidance about not using SHA-1.

Thanks,
Chris