Re: [secdir] secdir review of draft-ietf-syslog-sign-27

["Alexander Clemm (alex)" <[e-mail]>]

Hi,

 

Thank you for your review.  Please see responses, inline, delimited with
<ALEX>.  Please let me know if you feel that those responses adequately
resolve the issue, or clarify any problems that you feel have not been
adequately addressed.  

 

Thank you and kind regards

--- Alexander Clemm

 

From: Tina TSOU [mailto:[e-mail]] 
Sent: Tuesday, September 15, 2009 8:03 PM
To: secdir; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [secdir] secdir review of draft-ietf-syslog-sign-27

 

Sending to [e-mail]

 

 

B. R.
Tina

http://tinatsou.weebly.com/contact.html

	----- Original Message ----- 

	From: Tina TSOU <mailto:[e-mail]>  

	To: [e-mail] ; secdir <mailto:[e-mail]>  

	Cc: [e-mail] ;
[e-mail] 

	Sent: Wednesday, September 16, 2009 10:41 AM

	Subject: [secdir] secdir review of draft-ietf-syslog-sign-27

	 

	I have reviewed this document as part of the security
directorate's 
	ongoing effort to review all IETF documents being processed by
the IESG. 
	  These comments were written primarily for the benefit of the
security 
	area directors.  Document editors and WG chairs should treat
these 
	comments just like any other last call comments.
	In general, from the security point of view, this draft does not
specify what 
	the loghost should do in case of packet loss, DoS attack, etc.
Should the 
	device try to retrieve the sys log information again? 
	 
	Section 1, third paragraph (talking about Certificate Block):
not to 
	over-complicate matters, but this is really talking about the
content of a 
	Payload Block. Rather than introduce that term, perhaps rephrase
the paragraph 
	slightly to make clear that multiple Certificate Blocks may be
used. What's the key management information here? Is it Certificate
information or public key information?

	 

	    Additionally, a signer sends Certificate Blocks to provide
key
	    management information between the signer and the collector.
A
	    Certificate Block has a field to denote the type of key
material
	    which may be such things as a PKIX certificate, an OpenPGP
	    certificate, or even an indication that a key had been pre-
	    distributed.  In the cases of certificates being sent, the
	    certificates may have to be split across multiple
Certificate
	    Blocks carried in separate messages.

	 

	<ALEX>  Change accepted  

	</ALEX>

	 

	Section 1, fifth paragraph, first sentence: not clear what
"previous" refers to. 
	The phrase "of the previous messages" doesn't seem to add
anything and can be 
	dropped. Suggest adding "syslog" after "received" and
"corresponding" before 
	"Signature Block", so the sentence reads:

	 

	    The collector may verify that the hash of
	    each received syslog message matches the signed hash
contained in the
	    corresponding Signature Block.

	 

	 <ALEX> Change accepted

	</ALEX>

	 

	
	Section 4.2.3: It is strongly suggested that the field currently
identified as 
	Signature Group (SG) be renamed to Signature Group
Interpretation (SGI) to avoid 
	confusion. The statement that SPRI identifies the actual
signature group also 
	comes a bit late (beginning of the fourth paragraph). It should
be moved up to 
	the first paragraph.

	 

	Note that changing SG to SGI affects the tables in section 4.2
and 5.3.2 and IANA considerations. Note also that the field is called
SIG instead of SG in section 5.3.2.3.

	 

	<ALEX>  There does not seem to be a need for that change -
section 4.2.3 contains an additional clarification which clearly points
out the difference between SG field and the Signature Group itself; this
should be sufficient.

	</ALEX>

	 

	
	In section 5.3.2, P23, what's the main difference between using
Signature block and using Certificate block? It seems Certificate Block
overlaps with Signature Block, e.g., Both block are digitally signed,
why is only certificate block termed "certificate block", why not term
certificate block as "signature block"?

	 

	<ALEX>  

	The question is confusing.  The difference between Signature
Block and Certificate Block should be clear (as also evidenced from the
proposed text in the first comment) and there should be no issue that
they might be confused.  Signature Blocks contain the signatures of
previously sent messages, whereas Certificate Blocks contain key
material - two very distinct purposes.  No changes are made.

	</ALEX>

	 

	In section 5.3.2.9, the point is made that the timestamp of the
Certificate 
	Block message is the same as that of the Payload Block. In fact,
they differ 
	very slightly in the example. Is that intended?

	 

	<ALEX> 

	Proposed wording change as follows:

	                       Note that the Certificate Block message
in this example has a time stamp

	                       that is very close to the time stamp in
the Payload Block.  

	                       The fact that the time stamps are so
close implies that this is the first 

	                       Certificate Block message

	                       sent in this reboot session; additional
Certificate Block messages can be 

	                       sent later with a later time stamp, which
will carry the same Payload Block 

	                       that will still contain the same time
stamp.  

	</ALEX>

	 

	In section 6, near the bottom of the first paragraph, a couple
of words are 
	missing. It is suggested that the sentence be changed to read:

	 

	
The
	    collector MUST ignore duplicates of Signature Blocks and
Certificate
	                          ^^^^^^^^^^^^^^
	    Blocks it has already received and authenticated.

	 

	<ALEX>

	Suggested change is accepted.

	</ALEX

	 

	Section 7 is informative. Perhaps it belongs in an appendix.
	 

	<ALEX>

	There does not seem to be compelling reason to change the
structure at this point, propose to keep as is.

	</ALEX

	
	In section 7.1, 
	 4.  Set the last message number processed to the value of the
	           First Message Number plus the Count of the Signature
Block
	           minus 1.
	Why is the Last message number not defined in this document?
	 

	<ALEX>

	The last message number is in fact introduced in item b.  As it
is stated there clearly, it is a cursor that is maintained by the
collector to keep track of the point to which it has received message
signatures.  Additional explanation does not appear to be necessary.  

	</ALEX>

	 

	
	In section 8.1,
	 This specification uses Public Key Cryptography technologies.
The
	   proper party or parties have to control the private key
portion of a
	   public-private key pair.  Any party that controls a private
key can
	   sign anything it pleases.
	 
	As regarding the last sentence, Is it appropriate to use
"pleases" here? How about using *favors* or *prefers* instead of
*pleases*?
	 

	<ALEX>

	"Pleases" appears to be the appropriate term in this context -
it expresses that it can in effect do whatever it wants - "favors" or
"prefers" would imply there are a choices to select between, which does
not sound quite right in this context.  No change is made.  

	</ALEX>

	 

	
	In section 8.2,
	As a signer, it is advisable to avoid message lengths exceeding
2048
	   octets.  Various problems might result if a signer were to
send
	   messages with a length greater than 2048 octets, because
relays MAY
	   truncate messages with lengths greater than 2048 octets which
would
	   make it impossible for collectors to validate a hash of the
packet.
	   To increase the chance of interoperability, it tends to be
best to be
	   conservative with what you send but liberal in what you are
able to
	   receive.
	 
	   From the above paragraph, we can see it is necessary to
restrict
	   the length of message, So I would like to suggest changing
the last
	   sentence as:
	   "
	   To increase the chance of interoperability, it tends to be
best to 
	   limit the length of what you send but loose what you are able
to
	   receive.
	   "
	   to make it more precise. Is it reasonable to do this?
	
	

	<ALEX>

	The "conservative" and "liberal" saying dates back to Jon Postel
and RFC 760.  We think this should stay as is.  

	</ALEX>

	 
	 
	In section 8.3,
	Syslog does not strongly associate the message with the message
	   originator.  That association is established by the collector
upon
	   verification of the Signature Block. 
	   
	What's the difference between associating the message with the
message originator
	and signature? If they are the same thing, I think the
association should be pre-established
	in collector? Is it a correct understanding?
	
	

	<ALEX>

	 It is up to facility and application-ID to indicate who or what
actually triggered the original message; for the purposes of this here,
"originator" refers to the sender of the message, not the source of the
event that triggers the sending of the message.  The wording should
stand.  

	</ALEX> 

	 

	
	 
	In section 8.4,
	Event messages might be recorded and replayed by an attacker.
Using
	   the information contained in the Signature Blocks, a reviewer
can
	   determine whether the received messages are the ones
originally sent
	   by an originator.  The reviewer can also identify messages
that have
	   been replayed.

	 

	I am wondering what the information is in the signature block
can be used to
	prevent replaying? Count or sequence number, time stamp, if
there is such thing, it is better to
	point it out which field of signature block is used for
anti-replaying.
	 
	<ALEX> 

	Section 7 implicitly explains how messages can be identified
that have been replayed.  In that case, in step 3.b (section 7.1), the
authenticated log file would already contain the message.  Step 3.b does
not explicitly state to flag the fact that a replayed message was
received, but adding such a capability if desired would be near-trivial
(and IMHO hence does not need to be explained) and in any event the
authenticated log file would clearly contain only one instance of the
authenticated message.  

	To make it even clearer, the following wording is added to
section 8.4:

	 

	                       Using the methods for verification of
logs 

	                       outlined in Section 7, a replayed message
can be detected by checking

	                       prior to writing a message to the
authenticated log file whether the message is 

	                       already contained in it.

	</ALEX>

	 
	 
	 

	 

	B. R.
	Tina
	http://tinatsou.weebly.com/contact.html

	 

	 

	 

	 

________________________________

	_______________________________________________
	secdir mailing list
	[e-mail]
	https://www.ietf.org/mailman/listinfo/secdir