On 8/6/08 8:16 PM, Joseph Salowey (jsalowey) allegedly wrote:
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 PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Brim
Sent: Thursday, July 31, 2008 8:59 AM
To: [EMAIL PROTECTED];
[email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
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 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.
> 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.
Thanks ... Scott
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
