> -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 07, 2008 1:16 PM > To: [EMAIL PROTECTED]; Joseph Salowey (jsalowey); > [EMAIL PROTECTED]; > [EMAIL PROTECTED]; > [EMAIL PROTECTED]; gen-art@ietf.org > Subject: RE: [Syslog] gen-art review > ofdraft-ietf-syslog-transport-tls-13.txt > > 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]; gen-art@ietf.org > > 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. > [Joe] The implementation MUST abide by the configured policy. The implementation can allow for many different types of policies including ones that permit unauthenticated transport senders or receivers in sections 5.3 - 5.5. Implementations MUST support the policies defined in 5.1 and 5.2.
> dbh > > > > > Best regards, > > Pasi > > _______________________________________________ > > Syslog mailing list > > [EMAIL PROTECTED] > > https://www.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
