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. > > > 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). > "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). Best regards, Pasi _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
