Subject: [Syslog] Matters arising was: Re: syslog WG meeting minutes (proposed)

From: "tom.petch" <[email-masked]>
Date: Mon, 3 Aug 2009 11:59:04 +0200

Picking up on the point of commonality between DTLS for IPFIX, ISMS and syslog:

- having a common statement of how to check certificates would save work here
and elsewhere ie get draft-hodges-server-ident-check-00.txt to include as a
minimum the cases covered in syslog-tls and get that I-D progressing onto
standards track so as to use it as a normative reference (can we steal it from
apps into security:-).

- syslog has tls as RECOMMENDED transport at the insistence of the IESG because
it has flow control and the others do not.  DTLS over UDP has no flow control
and so, by analogy,  I would expect it to be unacceptable to the IESG ie it will
have to be DTLS over SCTP that will have to be there as well or instead
(something I did not think of in 2006).

- having written a DTLS I-D (and looked at many more), I am inclined to agree
with Wes that there will not be much in common (apart from certificate
checking - see above)

Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 30, 2009 4:50 PM
Subject: [Syslog] syslog WG meeting minutes (proposed)

> Hi Folks,
>
> Here are the meeting minutes that I took.  Please send back edits if you
> want anything changed.
>
> ===
> Meeting was started, blue sheets passed around, no one in jabber room
> other than the people in the room.
>
> Chairs went through the slides.
>
> Q about syslog/BEEP on slide 10: We're not proposing to standardize this;
> it's already RFC 3195.  Since the uptake on implementation (of this RFC,
> and of BEEP overall) is low, then the WG should consider moving the RFC to
> HISTORIC.
>
> Jurgen S. gave a review of his thoughts on the proposed new charter items:
> Slide 8,
>   MIB, OK
>   DHCP, has some operational value
>   don't need an architectural reference to be done in the IETF
> Slide 9
>   might be interesting to have a guideline but not sure who would commit
> the time to do that
>   DTLS, should be done and aligned with RFC 5425 (syslog/tls)
>   syslog/tcp, should be very straightforward and easy to do
>   syslog/BEEP, declare HISTORIC
>
> Dan R. - Since syslog WG is proposing to do syslog/DTLS is there enough
> commonality so that ISMS/DTLS and IPFIX/DTLS can re-use?
>   - Consensus was that this was likely.  David also noted that the others
> are also doing SCTP.
>
> Pasi E. - syslog/DTLS should be easy since it will draw directly from
> syslog/TLS.
>   - IPFIX also working on Dead Peer Detection (DTLS Heartbeet), we should
> likely support this as well.
>   - There were problems with the previous IPFIX/DTLS but that was because
> of bad libraries in OpenSSL which have since been fixed.
>
> Wes H. - there is not that much commonality between the schemes because of
> a lot of useage details.
>
> Chris and David have asked Joe Saloway to act as WG editor for the DTLS
> work.
>
> Meeting adjurned at 10am.
>
> ===
>
> Thanks,
> Chris
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 3 Aug 2009 06:52:56 -0700 (PDT)

Hi Tom,

> standards track so as to use it as a normative reference (can we steal it from

Sounds good.

> (something I did not think of in 2006).

I'm not that familiar with DTLS.  Can we just specify how to put syslog 
over it, or do we need to also state how it is to be layered above a 
substrate tranport such as sctp?  My preference would be to just define 
syslog/dtls and then have a pointer back to RFC 5424 (syslog Protocol) 
Section 8.6. (Congestion Control) which spells out the reason for choosing 
properly.  I'm really hoping that we don't have to create a document for 
anything other than syslog/dtls.

> with Wes that there will not be much in common (apart from certificate

If we _can_ just do XYZ/dtls (without having to go through the lower 
substrate definition) then the pieces of work are (imho):
- state how the specification addresses the threats identified in 
syslog/tls,
- explain certificate checking (as you note above)
- explain how records will be separated.

Can anyone think of anything else that needs to be defined in this work?

Tom, can a document just do XYZ/dtls, or does it also _really_ need 
definition for the substrate?

Thanks,
Chris

---

From: "tom.petch" <[email-masked]>
Date: Wed, 5 Aug 2009 17:32:10 +0200

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "syslog" <[email-masked]>; <[email-masked]>
Sent: Monday, August 03, 2009 3:52 PM

> definition for the substrate?

I can write such a document, but will the IESG accept it?  I don't know; I was
surprised at Magnus's DISCUSS two years ago on syslog-protocol that led us to
RECOMMEND a TLS transport, as opposed to UDP, on the grounds that it
offered congestion control and I doubt that concerns about congestion have
decreased since then.

So I am anticipating that syslog over DTLS with no mention of underlying
transport cannot be RECOMMENDED; perhaps a question for our AD to ponder, and
bounce off his transport area opposite numbers.

As to other points, my list, of what xxx-over-DTLS must consider is
    - authentication
    - connection set up
    - connection termination
    - choice of ciphersuite
    - choice of (D)TLS extensions
    - delineation of datagrams
    - invoking DTLS
    - fragmentation
and nowadays I must add
    - congestion control.

Tom Petch

> > Tom Petch
<snip>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Aug 2009 22:15:39 +0200

Hi,

To clarify a point ...
syslog/tls is not simply RECOMMENDED; it is MANDATORY TO IMPLEMENT.

syslog/dtls will be an optional transport; we do not need to RECOMMEND
it.
Implementers can decide for themselves whether to implement it.
I agree that the IESG may not approve it with congestion control
considerations.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of tom.petch
> Sent: Wednesday, August 05, 2009 5:32 PM
> To: Chris Lonvick
> Cc: syslog; [email-masked]
> Subject: Re: [Syslog] Matters arising was: Re: syslog WG 
> meeting minutes(proposed)
> 
> > > Picking up on the point of commonality between DTLS for 
> IPFIX, ISMS and
> syslog:
> > >
> > > - having a common statement of how to check certificates 
> would save work
> here
> > > and elsewhere ie get 
> draft-hodges-server-ident-check-00.txt to include as a
> > > standards track so as to use it as a normative reference 
> (can we steal it
> from
> > > apps into security:-).
> >
> > Sounds good.
> >
> > >
> > > - syslog has tls as RECOMMENDED transport at the 
> insistence of the IESG
> because
> > > it has flow control and the others do not.  DTLS over UDP 
> has no flow
> control
> > > and so, by analogy,  I would expect it to be unacceptable 
> to the IESG ie it
> will
> > > - having written a DTLS I-D (and looked at many more), I 
> am inclined to
> agree

---

From: "David Harrington" <[email-masked]>
Date: Wed, 5 Aug 2009 22:37:15 +0200

whoops
/with/without/

dbh 

> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Wednesday, August 05, 2009 10:16 PM
> To: 'tom.petch'; 'Chris Lonvick'
> Cc: 'syslog'; [email-masked]
> meetingminutes(proposed)
> > > over it, or do we need to also state how it is to be layered
above
> a

---

From: <[email-masked]>
Date: Fri, 7 Aug 2009 11:35:17 +0200

Tom Petch wrote:

> I can write such a document, but will the IESG accept it?  I don't
> know; I was surprised at Magnus's DISCUSS two years ago on
> syslog-protocol that led us to RECOMMEND a TLS transport, as opposed
> to UDP, on the grounds that it offered congestion control and I
> doubt that concerns about congestion have decreased since then.
> 
> So I am anticipating that syslog over DTLS with no mention of
> underlying transport cannot be RECOMMENDED; perhaps a question for
> our AD to ponder, and bounce off his transport area opposite
> numbers.
> 

About half of these seem to depend on the underlying transport
protocol (UDP/DCCP/SCTP/etc.) somehow, so I don't think a generic
XYZ-over-DTLS-over-anything document is really possible.

(But naturally e.g. both UDP and SCTP could be covered in
the same document, so this doesn't have to lead to explosion
in the number of internet-drafts...:-)

Best regards,
Pasi