Re: gen-art review ofdraft-ietf-syslog-transport-tls-13.txt

 

> -----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]; [email protected]
> 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]; [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. 
> 
[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
> > 
> 
> 
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog