Hi, > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, August 07, 2008 8:28 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; > [email protected]; [EMAIL PROTECTED] > Subject: Re: [Syslog] gen-art review > ofdraft-ietf-syslog-transport-tls-13.txt > > Joseph Salowey wrote: > > > > > 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." > > FWIW, I think capitalized "SHOULD" is correct usage here.
I agree. The implementation SHOULD provide the mechanism. If there is an issue of whether this is interoperable, then I could accept a MUST implement, but then we should probably describe the mechanism. > > > > > 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: > > Well, if the peer continues the connection, it *does* have a policy > that allows this (i.e. requirements of the policy are in fact > met, to some degree at least). Agreed. > > > "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." > > I think the correct fix would be to say that you MUST follow your > policy (instead of SHOULD), but you're allowed to have a policy > that permits unauthenticated transport senders (this kind of > policy is described in Section 5.3). I am just a bit concered about the use of RFC2119 terminology. MUST is for implementers; SHOULD is for deployers. Is that MUST directed at implementers or deployers? I agree that following the policy is important, and the implementation MUST abide by the policy. The deployer SHOULD be able to define a policy that permits unauthenticated senders. dbh > > Best regards, > Pasi > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
