Subject: [Gen-art] FW: Gen-ART LC Review of draft-ietf-syslog-sign-27 (fwd)

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 8 Oct 2009 23:34:05 -0700

Dear Ben, all, 

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

Thank you and kind regards
--- Alex

-----Original Message-----
From: Chris Lonvick (clonvick) 
Sent: Wednesday, September 16, 2009 12:20 PM
To: Alexander Clemm (alex)
Cc: David Harrington; Pasi Eronen
Subject: Gen-ART LC Review of draft-ietf-syslog-sign-27 (fwd)

Hi Alex,

These should be taken as WG-LC comments as well.

Pasi, do these need to be addressed for the IESG telechat?  (Or has that

already happened?)

Thanks,
Chris

---------- Forwarded message ----------
Date: Tue, 15 Sep 2009 17:26:16 -0500
From: To: [email-masked], David Harrington <[email-masked]>,
     [email-masked], General Area Review Team <[email-masked]>
Cc: IETF Discussion <[email-masked]>, Pasi Eronen <[email-masked]>
Subject: Gen-ART LC Review of draft-ietf-syslog-sign-27

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-syslog-sign-27
Reviewer: Ben Campbell	Review Date: 2009-09-15
IETF LC End Date: 2009-09-17
IESG Telechat date: (if known)

Summary:

This document is almost ready for publication as a draft standard. I
found a 
few minor issues that may need to be considered, and have a few
editorial 
comments

Major issues:

None

Minor issues:

4.2.2, 2nd to last paragraph: "It is up to implementations to ensure
that such 
a reset does not go undetected, for example by requesting operator 
acknowledgment when a reset is performed upon reboot."

Does this imply a normative requirement?

<ALEX>
No, this is not a normative requirement - how to deal with this issue
will be implementation specific.  
We discussed this on the mailing list using a printer as an example. 
The WG consensus was that a printer would likely signal to an 
operator via a text message on the display, a blinking light, or 
perhaps by some other means.  Since we don't want the printer to 
not function while waiting for any response from an operator, it's 
just a suggestion.
</ALEX>

4.2.3, list element "d": "There has to be some predefined arrangement
between 
the originator and the intended collectors..."

This makes me wonder how you ensure a collector does not receive
messages with 
an SG field of 3 that use some different mechanism than the expected
one. Does 
a "3" mean you have to have a single vendor? Some "trusted peer"
relationship 
that only includes signers with the same "3" interpretation?

Even if there's nothing normative here, it's worth a paragraph on the
issues of 
shared proprietary mechanisms when you might someday see messages from 
arbitrary sources.

<ALEX>
For the case that a collector does not know about a Signature Group,
adding the following additional text:

						A collector that
receives Signature Block messages of a Signature Group
						of whose scheme it is
not aware SHOULD 
						bring this fact to the
attention of the system administrator.  The particular
						mechanism used for that
is implementation-specific and outside 
						the scope of this
specification.  

For the case that the collector has a different understanding than the
sender about a Signature group: It is implied that if SG="3" is used,
there needs to be a predefined arrangement.  This option is not intended
for deployments which lack such an arrangement.  Adding the following
text:

							Note that this
option is not intended for 
							deployments
which lack such an arrangement, as in those cases a collector could 
							misinterpret the
intended meaning of the Signature Group.
</ALEX>

-- 5.2.1, a. 5. ("U")

(Same concern as in previous comment on SG field value of 3)

<ALEX>
It should be clear that this is installation-specific.  It is in effect
an "escape clause".  If non-installation specific key blobs are desired,
another value should be chosen.  No text change made.
</ALEX>

-- 5.2.2, a. "Comparing other forms of HOSTNAMEs is beyond the scope of
this 
specification."

Does this limit a host to a single cert for all signers? Or at least
require 
them all certs from the same host to match all possible signers on that
host? 
Is this acceptable? (Occurs elsewhere in the draft as well.)

<ALEX>
It does not limit a host to a single cert for all signers.  It merely
implies that the certificate must contain the hostname, but it doesn't
say that there can be only one certificate for a hostname. Each signer
might have its own.  In other words, this should be acceptable; no text
change made.
</ALEX>

-- 6, 1st paragraph: "...when syslog messages are sent over unreliable 
transport..."

I assume from this it is possible to send syslog over reliable
transports. 
Should there be guidance over whether to send redundant blocks when
using 
reliable transports?

<ALEX>
It is up to the implementer to decide if it is needed, therefore a
general guidance should not be required.  Note that it may make sense to
send Blocks redundantly even in the case of a reliable transport, as a
collector might be temporarily offline or even a reliable transport
connection might be temporarily released.  
</ALEX>

-- Section 7, general:

I don't seem to find any normative language on the verification of
signed 
messages. I don't expect every procedural step to say MUST or SHOULD,
but at 
least a "collector" or "processor" MUST/SHOULD follow these steps:" sort
of 
assertion would be good.

<ALEX>
Adding the following text at the beginning of section 7:
			This section outlines a method for online and a
method for 
			offline verification of logs which
implementations MAY
			choose to implement to verify logs efficiently.

			Implementations MAY also choose to implement a
different method; it is 
			ultimately up to each implementation how to
process the messages that 
			it receives.  
</ALEX>

-- Section 8, 2nd paragraph:

If I understand correctly, you need _some_ kind of external verification
of the 
certificate sent by a signer--either via a shared CA, or an explicitly 
configured trust assertion by the operator. This paragraph seems to
obscure 
that.

<ALEX>
I am not sure a modification is needed - do you have a suggestion of a
clarification that you would like to see?
</ALEX>

-- Section 8.4:

Can you elaborate on how the reviewer detects replay attacks (or
reference a 
section that does so?)

<ALEX>
Adding the following text: 
				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>

-- Section 9.3, "SG Field"

It would be nice to have a "meaning" column with some comment indicating
action 
meaning, and a separate "defined by" reference column.

<ALEX>
Not sure I understand this comment.  There is a "meaning" column.  The
meaning for all is defined in section 4.2.3, nowhere else in this
document, hence no separate column is needed.
</ALEX>

-- Section 10, working group mail list:

Is this address sufficiently long-lived to be a contact point in an
(assumedly 
immortal) RFC? (I think there has been some past IESG guidance on this
sort of 
thing, but don't remember what it was.)

<ALEX>
The assumption is yes as it is being rechartered
</ALEX>

Nits/editorial comments:

-- Section 1, paragraph 4, first sentence:

s/use their/uses its

<ALEX>
doublechecked the grammar, plural is correct
</ALEX>

-- Section 3, paragraph 2: "... MUST NOT be changed in transit"  (2 
occurrences)
Not clear what element this applies to--suggest restating in active
voice.

<ALEX>
The possibility that messages are changed in transit is also discussed
in RFC5424 which this document builds on top of.  Not sure a change is
needed.  
</ALEX>

-- Section 3, 2nd to last paragraph: "Therefore, the signature and
certificate 
data do not need to include any additional parameter to identify the
machine 
that orginates the message"

Should I read this to mean you are saying a certificate need not have
the 
relevant identity fields filled in? Give than binding an identity to a
public 
key is the most fundamental things certs do, I don't think you meant
that--but 
it's easy to read it that way.

<ALEX>
No, this does not talk about the certificate, just the signature and
certificate blocks (used to convey the certificate).  

To clarify, the following change is introduced to pargraph 3:
			The syslog messages defined in this document
carry the data that is associated with 
			Signature Blocks and Certificate Blocks
			as Structured Data.  

Then, the following change to paragraph 4:
			Therefore, the Signature Block and Certificate 
			Block data do not need to include any additional
parameter to identify the machine that orginates the 
			message.   

(The difference between Certificate Block and the certificate itself
should be clear.  There is no need for the Certificate Block to identify
the originator again - that would be redundant.)  
</ALEX>

-- Section 3, last paragraph:

Can multiple signers sign the same message? (I think the answer is yes,
as I 
don't see how the mechanism could stop them, but it's worth a mention.)

<ALEX>
Yes, the answer is yes.  Inserting an additional statement in
parantheses:
(By the same token, the same message might be
				signed by multiple signers.)  
</ALEX>

-- 4.2.3, 4th paragraph: "... as the name might suggest."

Given that the text acknowledges that the SG field name is confusing, is
it too 
late to give it a less confusing name?

<ALEX>
Don't intend to give it a different name at this point.
</ALEX>

-- 4.2.3, list element "a", "Signature Blocks sign..."

s/sign/apply to  (or "contain signatures for...")

<ALEX>
OK, changed to "contain signatures for"
</ALEX>

-- 4.2.9, paragraph 1: "ld6hg"

I don't see that string anywhere in the example

<ALEX>
Thank you, good catch; fixed
</ALEX>

-- 6.1.1, last paragraph, last sentence:

Suggest "MAY allow" rather than "MAY consider allowing..."

<ALEX>
OK, changed 
</ALEX>

-- section 7, general:

This section uses the form "We do...". I suggest changing "we" to the
relevant 
element or actor. Otherwise there is some risk of obscuring the
responsible 
party for each step.

<ALEX>
"We" refers to the implementation of the verification procedure.  This
should be pretty clear, leaving the text as is.  
</ALEX>

-- IDNits reports the following:

   Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
------------------------------------------------------------------------
----

   ** There are 8 instances of too long lines in the document, the
longest one
      being 1 character in excess of 72.
<ALEX>
fixed
</ALEX>

   -- Obsolete informational reference (is this intentional?): RFC 3164
      (Obsoleted by RFC 5424)
<ALEX>
The reference to RFC 3164 is used in the context of describing behavior
that serves as a "negative example" which is given in RFC 3164; RFC 5424
specifically rules out such behavior.  
Therefore, to be able to still refer to this as example for negative
behavior, the reference to RFC 3164 is still needed.</ALEX>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 9 Oct 2009 14:31:25 -0400

Hi,

Some comments as shepherd.

> not function while waiting for any response from an operator, it's

I agree this sounds normative. It might be better to say

"Implementations SHOULD ensure that such a reset does not go
undetected."

> Is this address sufficiently long-lived to be a contact point in an
The guidance can be found in
<http://www.ietf.org/id-info/guidelines.html>
http://www.ietf.org/id-info/guidelines.html

Note the the recharetr is only for about six months, so that's not a
good basis for assuming a long-lived adddress.

I expect we will keep the list open even after the WG closes, to
accommodate comments and questions, per the guidance.

dbh