----- Original Message ----- From: "Juergen Schoenwaelder" <[email protected]> Sent: Friday, February 05, 2010 10:34 AM
> 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? As Robert said, it is a SHOULD in RFC4347 which I think enough. > > 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? see above > > 4) in syslog, would it be better to specify the actions of the DTLS > > 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 > > clearly whether the "transport receiver" is the DTLS client or DTLS > > 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 > > 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 To follow a sentence saying this is a MUST with one that says it is not does not seem like an improvement to me. > > 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. agree > > -- 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. 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 > /js _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
