Subject: [Syslog] syslog/dtls and snmp/dtls

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Feb 2010 16:37:38 -0500

Hi,

I quickly looked at the two documents for differences.
I found a few I thought might deserve discussion:

-- DoS --

syslog:
Implementations MUST support
   the denial of service countermeasures defined by DTLS.  When these
   countermeasures are enabled, the transport receiver responds with a
   DTLS Hello Verify Request containing a cookie.  
snmp:
DTLS Transport
       Model server implementations MUST support DTLS cookies.

       Implementations are not required to perform the stateless
cookie
       exchange for every DTLS handshake, but in environments where an
       overload on server side resources is detectable by the
       implementation it is RECOMMENDED that the cookie exchange is
       utilized by the implementation.

My impression is that syslog allows an admin to enable this as a
deployment option; tlstm seems to depend on the implementation. (and I
have difficulty knowing how an implementation will know if overlaod on
server side is detectable, unless it is doing the detection itself.) 
1) Is enable/disable capability a MUST implement for DTLS cookie
exchange?
2) Should tlstm recognize whether it is enabled/disabled? 
3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in
syslog when the implementation can detect an overload on server
resources?
4) in syslog, would it be better to specify the actions of the DTLS
entity rather than "the transport receiver"? Does the draft spell out
clearly whether the "transport receiver" is the DTLS client or DTLS
server? When a syslog entity can act as both sender and receiver, what
is that implementation REQUIRED to support in terms of DTLS client and
DTLS server? I didn't see that in the text prior to section 5.3.1;
should this be made clear in the terminology section? Should there be
mandatory-to-implement text about this?

-- DCCP --

syslog/dtls supports the dccp transport:
   As the Internet best runs on the basis of appropriate resource
   sharing, SYSLOG over DTLS over DCCP [RFC5238] 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.  In those circumstances where reliability or ordering is
   important, SYSLOG over TLS is appropriate.  Syslog over TLS does
not
   provide application layer acknowledgements and therefore is not a
   fully reliable solution.
and
   DTLS can run over multiple transports.  Implementations of this
   specification MUST support DTLS over UDP and SHOULD support DTLS
over
   DCCP [RFC5238]. 
and
   When TCP is used syslog over DTLS MUST NOT be used.  If a secure
   transport is required with TCP then the appropriate mechanism is
   syslog over TLS.

although we are discussing:
Based on some advice from Lars, I recommend
s/Implementations of this specification MUST support DTLS over UDP and
SHOULD support DTLS over DCCP [RFC5238].  /
Implementations of this specification MUST support both DTLS over UDP
and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but
implementations of this specification MUST be prepared to support DCCP
where it is available."

I notice DCCP is not mentioned by TLSTM.
I'm not sure how much extra work it would take to add DCCP support to
snmp/dtls.

-- ports --

Since DTLS can run over DCCP, tlstm might want to define a domain for
that while you're at it (or not).

-- cipher suites --

syslog:
   Implementations MUST support DTLS 1.1 [RFC4347] and MUST support
the
   mandatory to implement cipher suite, which is
   TLS_RSA_WITH_AES_128_CBC_SHA.
tsltm:
	does not define a mandatory-to-implement cipher suite. 

Could this impact interoperability? I know this is one of those points
that keeps getting discussed. 
1) A mandatory-to-implement cipher suite ensures that different
implementations will have at least one suite that cna be used for
interoperability. 
2) But doesn't DTLS already define mandatory-to-implement cipher
suites? Do we need to do that here as well? Isn't it inherited from
DTLS?

How's this for a discussion starter?

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Feb 2010 10:34:23 +0100

> mandatory-to-implement text about this?

I suggest that some DTLS expert suggests text that is adequate.  It
seems to me that the ISMS text is better than the SYSLOG text but I am
not too deeply involved in DTLS matters.
 
> I'm not sure how much extra work it would take to add DCCP support to

Nobody ever asked for DCCP and I am reluctant to start new efforts to
add DCCP support. SNMP runs over UDP for more than 20 years and for a
single CG-CR transport, transactions are pretty much stop-and-wait
(multi-threaded retrievals like those described in RFC 1187 never
really took off because they spoil the caching on typical
agents). SYSLOG is quite different here since it is fire-and-forget
and as such a SYSLOG sender will never adapt to the speed of the
network. In other words, unless Lars raises a flag that SNMP over UDP
is not acceptable anymore after 20+ years of deployment, I am
reluctant to add explicit text concerning DCCP. And if Lars
successfully raises a flag that SNMP over UDP is not acceptable
anymore, we do have a bigger problem to solve.

> that while you're at it (or not).

The ISMS WG never asked for DCCP and unless the IESG requires us to
add DCCP support, I do not think we need to do this.
 
> suites? Do we need to do that here as well? Isn't it inherited from

This was discussed in the ISMS WG and I think we concluded that the
TLS specs define mandatory to implement cipher suites and that it is
counter productive to have our own list since we want to pick up new
mandatory cipher suites in case TLS specs move on because e.g. a
cipher is broken. In short, it is the job of the TLS specs to define
mandatory to implement ciphers.

/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: "tom.petch" <[email-masked]>
Date: Fri, 5 Feb 2010 14:56:59 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
Sent: Friday, February 05, 2010 10:34 AM

> > 1) Is enable/disable capability a MUST implement for DTLS cookie

As Robert said, it is a SHOULD in RFC4347 which I think enough.

> > syslog when the implementation can detect an overload on server

see above

> > entity rather than "the transport receiver"?

No.  SNMP subdivides the solution space into many more pieces,
introducing EOPs, ASIs, etc in order to do so.

syslog takes a much simpler view of what the implementer needs to
be told, and I think there is no merit in subdividing the stack further.
Once started, where do you stop?  Adding tlstm section 5.5.1?:-)

> >                                                            Does the draft
spell out
> > server?

syslog-dtls 5.2.  Port Assignment

 A SYSLOG transport sender is always a DTLS client and a transport
 receiver is always a DTLS server.

> >            When a syslog entity can act as both sender and receiver, what

To follow a sentence saying this is a MUST with one that says it is not does not
seem like an improvement to me.

> anymore, we do have a bigger problem to solve.

agree

> mandatory to implement ciphers.

The counter argument is twofold.  One is that the (D)TLS specs move
on in a world of their own, probably leading edge and out of this world for
many users thereof.  Thus the recent discussions on renegotiation have
highlighted
how many people are using SSL and how many implementations do not
conform to the enhancements introduced in TLS1.0 ie (a part of) the real
world is 11 years behind the cryptographic experts.  Including the current
received wisdom gives a sanity check.

Second, users have to go find it, they have to navigate their way through the
RFC chain, understanding that RFC are never re-issued but may be superseded,
so if they want the latest view, they need to consult and understand rfc-index.

What I am hinting at here is that my experience of the syslog list is very
different
to that on eg OPSAWG or isms; the former has less of the IETF culture,
more of people doing their own thing and needing a little steer in the right
direction.  I did survey the then current specs of application-over-TLS for this
and found that some do, some don't, and that 'do' seemed right for syslog.

Tom Petch

---

From: Robert Story <[email-masked]>
Date: Thu, 4 Feb 2010 21:09:03 -0500

On Wed, 3 Feb 2010 16:37:38 -0500 David wrote:
DH> syslog:
DH> Implementations MUST support
DH>    the denial of service countermeasures defined by DTLS.  When these
DH>    countermeasures are enabled, the transport receiver responds with a
DH>    DTLS Hello Verify Request containing a cookie.  
DH> snmp:
DH> DTLS Transport
DH>        Model server implementations MUST support DTLS cookies.
DH> 
DH>        Implementations are not required to perform the stateless
DH> cookie
DH>        exchange for every DTLS handshake, but in environments where an
DH>        overload on server side resources is detectable by the
DH>        implementation it is RECOMMENDED that the cookie exchange is
DH>        utilized by the implementation.
DH> 
DH> My impression is that syslog allows an admin to enable this as a
DH> deployment option; tlstm seems to depend on the implementation.

Hmm... DTLS says that cookies MUST be supported, so it seems like
simply mentioning that admins can enabled it, as opposed to only
RECOMMENDING it under special circumstances, would bring the two in
line.

DH> 1) Is enable/disable capability a MUST implement for DTLS cookie
DH> exchange?

Does syslog have this MUST, or simply a mention of 'when it is enabled'
implying it is configurable? I agree that parity would be good, and it
would be nice for it to be configurable.

DH> Since DTLS can run over DCCP, tlstm might want to define a domain for
DH> that while you're at it (or not).

Couldn't hurt to add a domain and say implementations MAY support DCCP,
but I don't think it's worth it if it's going to hold up the document.

DH> Could this impact interoperability? I know this is one of those points
DH> that keeps getting discussed. 
DH> 1) A mandatory-to-implement cipher suite ensures that different
DH> implementations will have at least one suite that cna be used for
DH> interoperability. 
DH> 2) But doesn't DTLS already define mandatory-to-implement cipher
DH> suites? Do we need to do that here as well? Isn't it inherited from
DH> DTLS?

I vote for 2, that we inherit from DTLS...

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 06 Feb 2010 00:18:34 -0500

>> anymore, we do have a bigger problem to solve.

As do I

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Feb 2010 09:21:48 -0800

>>>>> On Wed, 3 Feb 2010 16:37:38 -0500, "David Harrington" <[email-masked]> said:

[cut to just the ISMS document's wording:]
DH> DTLS Transport Model server implementations MUST support DTLS
DH> cookies.

DH> Implementations are not required to perform the stateless cookie

[And your comments:]
DH> My impression is that syslog allows an admin to enable this as a
DH> deployment option; tlstm seems to depend on the implementation. (and I
DH> have difficulty knowing how an implementation will know if overlaod on
DH> server side is detectable, unless it is doing the detection itself.)
DH> 

Actually, we require it to be implemented but we're rather flexible on
how it's actually used.  Intentionally.  I decided that there wouldn't
be problems if different implementations did different things.  Some
implementations could have it configurable; others could do automatic
detection, etc.  So we certainly support the same case that syslog is
doing, but we also allow implementations more flexibility.  I don't
believe this impacts interoperability of our base protocol.

Not currently.

DH> 2) Should tlstm recognize whether it is enabled/disabled? 

That's diving into protocol layers we said we wouldn't dive into.
Specifically, I was requested not mention DTLS specific protocol message
types in the document (like the syslog/DTLS document does).

DH> 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in
DH> syslog when the implementation can detect an overload on server
DH> resources?

Then that would prohibit an implementation from doing a runtime
on/off/maybe setting.  So personally, no, I don't see the need.  But I
also don't feel strongly about it.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Feb 2010 09:23:18 -0800

>>>>> On Fri, 5 Feb 2010 10:34:23 +0100, Juergen Schoenwaelder <[email-masked]> said:

>> -- cipher suites --

JS> This was discussed in the ISMS WG and I think we concluded that the
JS> TLS specs define mandatory to implement cipher suites and that it is
JS> counter productive to have our own list since we want to pick up new
JS> mandatory cipher suites in case TLS specs move on because e.g. a
JS> cipher is broken. In short, it is the job of the TLS specs to define
JS> mandatory to implement ciphers.

I agree; that's my recollection too (and one I agree with).
-- 
Wes Hardaker
Cobham Analytic Solutions