On Wed, Feb 03, 2010 at 10:37:38PM +0100, David Harrington wrote: > -- 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?
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. > -- 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. 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. > -- ports -- > > Since DTLS can run over DCCP, tlstm might want to define a domain for > 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. > -- 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? 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/> _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
