Subject: Re: [Gen-art] [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 6 Aug 2008 17:16:30 -0700

Thanks for reviewing the document, the comments are very useful.  I'm
including some comments and proposed resolutions below.  

Cheers,

Joe

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott Brim
> Sent: Thursday, July 31, 2008 8:59 AM
> To: [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: [Syslog] gen-art review of 
> draft-ietf-syslog-transport-tls-13.txt
> 
> I have been selected as the General Area Review Team 
> (Gen-ART) reviewer for this draft (for background on Gen-ART, 
> please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please wait for direction from your document shepherd or AD 
> before posting a new version of the draft.
> 
> Document: draft-ietf-syslog-tls-13.txt
> Reviewer: Scott Brim
> Review Date: 30 July 2008
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits 
> that should be fixed before publication.
> 
> Comments:
> 
> There is only one item that is significant, which is the last 
> of the SHOULD comments (just below).  As for the rest, they 
> are not showstoppers but imho if you take them into 
> consideration you'll have a better draft.
> 
> First, MUST/SHOULD
> ------------------
> 
>  >    TLS typically uses certificates [RFC5280] to authenticate peers.
>  >    Implementations MUST support TLS 1.2 
> [I-D.ietf-tls-rfc4346-bis] and
>  >    are REQUIRED to support the mandatory to implement cipher suite,
> 
> Small: Change "are REQUIRED to" to "MUST".
> 
>  >    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."

>  >    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:

"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."
 
> 
> Second, terminology
> -------------------
> 
> You have
> 
>    Transport sender	    Transport receiver
>    Server    		    Client
>    Peer			    Peer
> 
> These terms overlap.  I can't tell if the first two pairs are 
> synonymous or not.  I can see reasons to use all of these, 
> based on different relationships and functions, but you seem 
> to mix and match sometimes.  Sometimes limiting your 
> terminology can make your spec tighter and clearer, so 
> consider getting rid of one pair.  Here are some
> examples:

[Joe] The intent here was to align with the syslog terminology, while
mapping to the appropriate TLS terminology when discussing TLS specific
details.  Peer is used when describing behavior that is independent of
client and server roles. More below.

>  > 1.1 Terminology
>  >
>  >    o  A "TLS client" is an application that can initiate a TLS
>  >       connection by sending a Client Hello to a peer.
>  >
>  >    o  A "TLS server" is an application that can receive a Client
>  >       Hello from a peer and reply with a Server Hello.
> 
> Small: If you're going to use client, then use server, and vice versa.
> A TLS client initiates a Client Hello to a *server*, and a 
> server receives a Client Hello from a *client*.

[Joe] OK makes sense. 

>  > 4.1 Port Assignment
>  >
>  >    A syslog transport sender is always a TLS client and a transport
>  >    receiver is always a TLS server.
> 
> I would have thought that since a server occasionally sends a 
> message to the client (for example a close_notify), that the 
> server could be a "transport sender" too ... and similarly 
> the client receiving packets could be a "transport receiver".
> 

[Joe] Transport receiver and transport sender roles are with respect to
syslog messages.  TLS introduces its own signaling (close_notify and
others), but this does not change the roles of the syslog entities.

>  > 4.2 Initiation
>  >
>  >    The transport sender should initiate a connection to the
>  >    transport receiver and then send the TLS Client Hello to begin
>  >    the TLS handshake.  When the TLS handshake has finished the
>  >    transport sender MAY then send the first syslog message.
> 
> There are two actions here, "initiate a connection" and then 
> have a TLS handshake.  It would make more sense to me to use 
> the terms client/server than sender/receiver.
> 
[Joe] In the above cases the use of transport sender and transport
receiver are consistent with their use in the syslog protocol.

>  >    A TLS client MUST close the associated TLS connection if the
>  >    connection is not expected to deliver any syslog messages later.
> 
> Just above, the "transport sender" was told to set the 
> message length, but here the "TLS client" is told to close 
> the TLS connection.  That feels inconsistent.
[Joe] OK, I think it would make sense to use the syslog terminology here
to be consistent so this section should read:

   A transport sender MUST close the associated TLS connection if the
   connection is not expected to deliver any syslog messages later.  It
   MUST send a TLS close_notify alert before closing the connection.  A
   sender MAY choose to not wait for the receiver's close_notify alert
and
   simply close the connection, thus generating an incomplete close on
   the receiver side.  Once the receiver gets a close_notify from the
   sender, it MUST reply with a close_notify unless it becomes aware
   that the connection has already been closed by the sender (e.g., the
   closure was indicated by TCP).

   When no data is received from a connection for a long time (where the
   application decides what "long" means), a receiver MAY close the
   connection.  The receiver MUST attempt to initiate an exchange of
   close_notify alerts with the sender before closing the connection.
   Receivers that are unprepared to receive any more data MAY close the
   connection after sending the close_notify alert, thus generating an
   incomplete close on the sender side.  When the sender has received
   the close_notify alert from the receiver and still has pending data
to
   send, it SHOULD send the pending data before sending the close_notify
   alert.

> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/syslog
> 
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Scott Brim <[email-masked]>
Date: Thu, 07 Aug 2008 08:14:41 -0400

> meet traceability requirements."

If something is "necessary to meet ... requirements", isn't it a MUST?

My original question was just for a little clarification, but I would 
guess you're better off with the original sentence. :-)

The point of all this is to avoid ambiguity for implementers.  Most 
implementers seem to reflexively treat a SHOULD as a MAY, i.e. they 
don't bother ... unless they are authors of the draft, in which case 
they understand the implications much better and they make an informed 
decision.  So the point is to make it possible for a new reader to make 
an informed decision.

Everything below looks good.

>    send, it SHOULD send the pending data before sending the close_notify

Thanks ... Scott

---

From: <[email-masked]>
Date: Thu, 7 Aug 2008 15:28:27 +0300

Joseph Salowey wrote:

> [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. 
 
> [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).

> 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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 7 Aug 2008 16:15:59 -0400

Hi, 

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, August 07, 2008 8:28 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Syslog] gen-art review 
> ofdraft-ietf-syslog-transport-tls-13.txt
> 
> Joseph Salowey wrote:
> 

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.

> met, to some degree at least).

Agreed.

> 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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 7 Aug 2008 13:27:03 -0700

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, August 07, 2008 1:16 PM
> To: [email-masked]; Joseph Salowey (jsalowey); 
> [email-masked]; 
> Subject: RE: [Syslog] gen-art review 
> > > > 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?
> 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.
> 
> >  
> > > > 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.
> > > >
> > that allows this (i.e. requirements of the policy are in 
> fact met, to 
> > some degree at least).
> 
> Agreed.
> 
> > 
> > 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 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.