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. 

dbh

> 
> Best regards,
> Pasi
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/syslog
>