Thanks for reviewing the document, the comments are very useful. I'm including some comments and proposed resolutions below.
Cheers, Joe > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Scott Brim > Sent: Thursday, July 31, 2008 8:59 AM > To: [EMAIL PROTECTED]; > [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Syslog] gen-art review of > draft-ietf-syslog-transport-tls-13.txt > > I have been selected as the General Area Review Team > (Gen-ART) reviewer for this draft (for background on Gen-ART, > please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-syslog-tls-13.txt > Reviewer: Scott Brim > Review Date: 30 July 2008 > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > Comments: > > There is only one item that is significant, which is the last > of the SHOULD comments (just below). As for the rest, they > are not showstoppers but imho if you take them into > consideration you'll have a better draft. > > First, MUST/SHOULD > ------------------ > > > TLS typically uses certificates [RFC5280] to authenticate peers. > > Implementations MUST support TLS 1.2 > [I-D.ietf-tls-rfc4346-bis] and > > are REQUIRED to support the mandatory to implement cipher suite, > > Small: Change "are REQUIRED to" to "MUST". > > > 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. > > Medium: In general it's good to explain the conditions under > which a SHOULD is not expected. Otherwise you get some > implementations that treat it as a MUST and many others that > just ignore it. What happens if the sender or receiver does > not record the end-entity certificate? > Under what conditions is that a problem? > [Joe] Perhaps this SHOULD should not be capitalized. I think the purpose for the should is described, but perhaps it can be clarified: "The transport receiver and transport sender should provide a mechanism to record the end-entity certificate to correlate the authenticated party with the sent or received data in the case that it is necessary to meet traceability requirements." > > If the peer does not meet the requirements of the > security policy, > > the TLS handshake SHOULD be aborted with an appropriate > TLS alert. > > Medium-Large: This SHOULD surprises me. You allow the peer > not to abort the handshake under some conditions? What could > those conditions be? I think you should explain this SHOULD > carefully so as to avoid a security hole through lack of > documentation. > [Joe] The intent here is that a peer could accept a connection that does not meet a specific policy so it can continue operation. This does have some security implications. I think it is warranted to add explanatory some text along the lines of: "In traditional syslog using UDP as the transport, network administrators regularly set up syslog transport senders without performing any administrative tasks on the corresponding transport receivers. This behavior would be replicated by permitting a transport sender that may not meet the requirements of the security policy to send messages to a transport receiver so that the event messages may still be received. Of course accepting connections outside of policy increases the risk of compromise from the various threats that the use of TLS is attempting to mitigate. This must only be done when there are other mechanisms in place to manage the associated risks." > > Second, terminology > ------------------- > > You have > > Transport sender Transport receiver > Server Client > Peer Peer > > These terms overlap. I can't tell if the first two pairs are > synonymous or not. I can see reasons to use all of these, > based on different relationships and functions, but you seem > to mix and match sometimes. Sometimes limiting your > terminology can make your spec tighter and clearer, so > consider getting rid of one pair. Here are some > examples: [Joe] The intent here was to align with the syslog terminology, while mapping to the appropriate TLS terminology when discussing TLS specific details. Peer is used when describing behavior that is independent of client and server roles. More below. > > 1.1 Terminology > > > > o A "TLS client" is an application that can initiate a TLS > > connection by sending a Client Hello to a peer. > > > > o A "TLS server" is an application that can receive a Client > > Hello from a peer and reply with a Server Hello. > > Small: If you're going to use client, then use server, and vice versa. > A TLS client initiates a Client Hello to a *server*, and a > server receives a Client Hello from a *client*. [Joe] OK makes sense. > > 4.1 Port Assignment > > > > A syslog transport sender is always a TLS client and a transport > > receiver is always a TLS server. > > I would have thought that since a server occasionally sends a > message to the client (for example a close_notify), that the > server could be a "transport sender" too ... and similarly > the client receiving packets could be a "transport receiver". > [Joe] Transport receiver and transport sender roles are with respect to syslog messages. TLS introduces its own signaling (close_notify and others), but this does not change the roles of the syslog entities. > > 4.2 Initiation > > > > The transport sender should initiate a connection to the > > transport receiver and then send the TLS Client Hello to begin > > the TLS handshake. When the TLS handshake has finished the > > transport sender MAY then send the first syslog message. > > There are two actions here, "initiate a connection" and then > have a TLS handshake. It would make more sense to me to use > the terms client/server than sender/receiver. > [Joe] In the above cases the use of transport sender and transport receiver are consistent with their use in the syslog protocol. > > A TLS client MUST close the associated TLS connection if the > > connection is not expected to deliver any syslog messages later. > > Just above, the "transport sender" was told to set the > message length, but here the "TLS client" is told to close > the TLS connection. That feels inconsistent. [Joe] OK, I think it would make sense to use the syslog terminology here to be consistent so this section should read: A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A sender MAY choose to not wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver side. Once the receiver gets a close_notify from the sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a receiver MAY close the connection. The receiver MUST attempt to initiate an exchange of close_notify alerts with the sender before closing the connection. Receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the sender side. When the sender has received the close_notify alert from the receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
