Hi Anton, inline
Tom Petch ----- Original Message ----- From: "Anton Okmyanskiy (aokmians)" <[email protected]> To: <[email protected]> Sent: Friday, February 19, 2010 11:15 PM Subject: [Syslog] Please review draft-ietf-syslog-dtls-01 > Chris asked me to review this draft. Comments below. > > Section 1 > > "DTLS has been mapped onto different transports (i.e. UDP [RFC0768] and > DCCP [RFC4340] ), to secure syslog in more situations." > > AO: Remove " to secure syslog in more situation". This paragraph is > giving a general overview of DTLS and it is independent of syslog. > Otherwise, reader is confused into thinking that DTLS was mapped as > described for the benefit of syslog. What I find that phrase adds is a justification for syslog over DTLS to exist; it caters for situations where the TCP problems alluded to in the previous paragraph are an issue; perhaps rephrase it as "which makes it possible to secure applications such as syslog in a greater variety of situations". > "For systems where DCCP is either not available or not usable (such as > the aforementioned situation)," > > AO: Don't see any "aforementioned situation" in text or don't get the > reference. Again, I think that this harks back to para 2 which puts the case for UDP and implicitly against DCCP. > "In those circumstances where reliability or ordering is important, > SYSLOG over TLS is appropriate." > > AO: This would be best moved to end of first paragraph where Syslog over > TLS is introduced. Yup > "Syslog over TLS does not provide application layer acknowledgements and > therefore is not a fully reliable solution." > > AP: Same comment as above. This criticism leaves a question as to > whether the newly defined mapping solves this problem. If not, it should > be pointed out as a drawback of both mappings, not just TLS. Possibly, > best addressed elsewhere in a Reliability section. No, it does not change the application layer protocol, and this is a general weakness of TCP which seems not to be as well known as it might be and so should be included; perhaps the first paragraph is best. We have a delicate juggling act here, that syslog over TLS is the IESG-mandated solution, because it provides flow control, and so we cannot be too critical of it, yet need to criticise it in order to justify the existence of sylog over DTLS. > Section 2 > > "A "DTLS client" is an application that can initiate a DTLS Client Hello > to a server." > > AO: Further in the document we have... > > " The transport sender initiates a DTLS connection by sending a DTLS > Client Hello to the transport receiver. > > "A SYSLOG transport sender is always a DTLS client and a transport > receiver is always a DTLS server." > > AO: Why do we need 4 terms then? If they are equivalent, may be best > to just add further description to transport sender/receiver and stick > them? Bear in mind that RFC5424 prescribes a set of syslog terms that have nothing to do with (D)TLS and those should be used as is; we then need terms for the (D)TLSish things and I think that this is the minimum necessary. Who is client and who server is a big deal with (D)TLS and needs to be explicitly stated in application terms. > > Section 3 > > " The security requirements for Syslog are discussed in [RFC5425]." > > AO: Suggest changing to: " The security requirements for Syslog are > discussed in Section 2 of [RFC5425] and apply to this transport > mapping." Yup > Section 5.3.1 > > " 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." > > AO: Which exact fields of the certificate? Surely not entire > certificate. Maybe full DN + SubjectAltName + AuthorityKeyIdentifier? I think that these are murky waters; something similar cropped up on the TLS list recently with the view that this is really a task for PKIX, even if they show no signs of wanting to take it on. Outside PKIX, I think that we should restrict ourselves to entire certificates (or to fingerprints thereof, when appropriate). > Section 5.4.1 > > The message size SHOULD NOT exceed the DTLS maximum record size > limitation of 2^14 bytes. > > AO: SHOULD NOT or MUST NOT? > > When mapping onto different transports, DTLS has different record size > limitations. > > AO: Can we mention limitations with UDP and DCCP here, so people don't > have to dig and do the math on extra size header overhead? Another murky water on which I will pass. tp > Anton. > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
