Hi, Chris Lonvick asked me to review draft-ietf-syslog-dtls-01 and here are my comments. I believe the document is not yet ready for the IESG and needs at least one update to improve on a number of details. For sake of simplicity, I will quote the relevant part of the ID and then comment it.
The datagram transport layer security protocol (DTLS) [RFC4347] is designed to meet the requirements of applications that need secure datagram transport, by combining UDP transport with TLS security. DTLS has been mapped onto different transports (i.e. UDP [RFC0768] and DCCP [RFC4340] ), to secure syslog in more situations. I think ", to secure syslog in more situations" serves no value here. important, SYSLOG over TLS is appropriate. Syslog over TLS does not provide application layer acknowledgements and therefore is not a fully reliable solution. I do not understand why the last sentence is here. The purpose of this document should be to define SYSLOG over DTLS and not to discuss the properties of other SYSLOG transports. The term "connection" used in this document is used to refer to a secure association between transport sender and transport receiver that permits the transmission of one or more SYSLOG messages within the lifetime of the connection. Do we need this term "connection"? There is a potential for confusion, e.g. the abstract talks about "connection-less transport" and hence there are multiple meanings of "connection" in place. If we need the term, we should perhaps call it a "DTLS connection" and make sure we use the full term everywhere. Also "secure association between transport sender and transport receiver" can be anything secure, not particularly DTLS - was that the intention? Syslog messages are secured in a hop-by-hop manner. The security requirements for Syslog are discussed in [RFC5425]. I believe this is not quite right. Signed SYSLOG messages seem to provide end-to-end authentication, contradicting the first sentence. My reading of Section 3 of RFC 5425 (you might want to be explicit) is that it talks primarily about requirements for secure SYSLOG transports and not SYSLOG per se. TLS typically uses certificates [RFC5280] to authenticate peers. I am not sure why this sentence is there. I suggest to remove it. 5.3.1. Certificate-Based Authentication I suggest to either drop this headline or make this 5.4 instead of 5.3.1, flattening the structure of the document. But I have no strong opinion about this. OK, I just figured out it this document is following the structure of RFC 5425. Perhaps should should be mentioned somewhere explicitly (if that is a reasonable organization, which could also be discussed). Both transport receiver and transport sender implementations MUST provide means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism. I do not know the idea behind this requirement is or how I comply to it. Is this expressing a requirement for the management interface of the box? Or is the idea that this is used in some automated fashion (which likely does not make sense but would be harmful if read this way). The transport receiver and transport sender SHOULD provide mechanisms to record the end-entity certificate for the purpose of correlating it with the sent or received data. What is an end-entity certificate? And how do I correlate sent or received data? The message length is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME. A transport receiver MUST use the message length to delimit a syslog message. There is no upper limit for a message length per se. As stated in [RFC4347], each DTLS record must fit within a single DTLS datagram. When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. The text in 5.4 said the following: [...] It is possible that multiple syslog messages be contained in one DTLS record, or that a syslog message be transferred in multiple DTLS records. This seems to be contradictory. If I can fragment a syslog message over multiple DTLS records, why should a message not exceed the DTLS maximum record size? So do we do fragmentation / reassembly of syslog messages, yes or no? If yes, perhaps some text should be added discussing the implications (delivery of DTLS records is not reliable). [...] Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify. Is it our job to define this? Does DTLS not specify how to handle such DTLS alerts? Syslog applications SHOULD be implemented in a manner that permits administrators, as a matter of local policy, to select the cryptographic level and authentication options they desire. What is "cryptographic level"? If this refers to the selection of crypto algorithms, isn't this implementation SHOULD generally true for crypto protocols and isn't DTLS designed to do this? Is it needed to spell this out here? [...] An exiting DTLS session MUST NOT be reused if its protection does not match the minimum policy requirements of the new SYSLOG over DTLS session request. I am not sure what "reuse" means here. Some more explanation is needed to understand this concept of reuse. /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
