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-gennai-smime-cnipa-pec-05
Reviewer: Ben Campbell
Review Date: 2009-11-03
IETF LC End Date: 2009-11-10
IESG Telechat date: (if known)
Summary: This draft has significant open issues. I am not sure if it lands in
the "open issues but on the right track", or "serious issues and needs to be
rethought" category. The answer to that depends on the outcome of my "why is
this standards track?" comments below.
*** Note: I have concerns (below) about whether this should be a standards
track or informational document. I have, however, continued the review it under
the assumption that it will remain standards track. If it is decided that it
should not be standards track, then many if not most of my "issue" comments
will no longer apply. ***
Major issues:
-- Why is this standards track?
If I understand it correctly, this is a restatement of a specification produced
by the government of Italy, and standardized there by an act of law. It's not a
standard produced by the IETF per se. It seems to me that this should at best
be an informational, and might even belong in the independent submission
stream. Furthermore, I assume that the Italian document on which this is based
is the authoritative statement of this standard, and that the government of
Italy has change authority, not the IETF. One wonders why we need to publish
anything more than a reference to the base document(s).
If we publish this as a PS, does that imply that the IETF thinks that the
security properties are adequate for the purpose?
-- Normative Requirements concerning Matters of Policy
This draft has a number of normative requirements that I think are more matters
of law and provider business policies than technical requirements. For example,
providers MUST keep a log of all activities. This sort of thing might belong in
a BCP, but seems not appropriate in an IETF standards track document. (It is
reasonable to describe matters of law for motivational purposes, but that
should not be in the form of normative requirements.)
-- Virus Checking
This spec has MUST level normative requirements for PEC elements to perform
virus checking. It offers, however, no description, or references to
descriptions, of how one does that. Nor does it offer any criteria of what sort
of virus checking systems might meet the requirements of the overall system.
But given the realities of the virus checking arms race, I don't think this is
appropriate as a normative requirement in a proposed standard even if was
adequately specified. (See previous comment about conflating technical
standards and matters of policy).
Minor issues:
-- Copyright notice:
What is the copyright status of the Italian document on which this is based?
Does it have implications on the copyright status for this document?
-- Section 2.1, paragraph 7:
I am concerned about directing anyone to create a display name that does not
describe the address itself. Also, the example loses the original display name
completely.
-- section 2.1.1.1:
Why use "X-" headers in a proposed standard? Usually that denotes a proprietary
or otherwise non-standard header field.
-- section 2.2.1, Paragraph 3, "if a formal exception is detected, the access
point refuses the
message and emits the relevant non-acceptance PEC notification
(see section 3.1.1);"
It's not clear to me if you mean for the SMTP transaction itself to be
rejected, or to succeed but result in a non-acceptance notification. I have the
same question for several other areas where you talk about a PEC element
refusing a message.
-- same section, paragraph 7: "The identifier (from now on PEC msgid) of
accepted original messages
within the PEC infrastructure MUST be unambiguous in order to
consent correct tracking of messages and relative PEC notifications."
I _think_ you are saying the PEC msgid must be globally unique, right? If so,
you need to say something more about how it's guaranteed to be unique. Also,
what does "…consent correct tracking…" mean?
-- same section, general discussion about Message-ID: "Therefore, both the
original message and the corresponding PEC
transport envelope MUST contain the following header field:
Message-ID: <[unique identifier]> "
I'm confused. Are you saying the PEC msgid _is_ the Message-ID: header field?
If so, is the SMTP requirement for this field not sufficient?
"When an email client that is interacting with the access point has
already inserted a Message ID (from now on msgid) in the original
message, that msgid SHALL be substituted by a PEC msgid."
I'm more confused. Won't Message-ID _always_ be in the original message? Isn't
it already guaranteed unique? Why do you need to change it? I am concerned
about a system rewriting the original message-id of an email. If the
access-point rewrote the original Message-ID with something else, how will the
sender's client learn of it in order to correlate?
-- section 2.2.2, "Signature Origin" bullet point:
I'm a little surprised that one determines that a domain is a PEC provider by
looking up the hash of its certificate in a directory. Couldn't this be more
easily accomplished by some assertion in the certificate itself, signed by a
designated CA? Could someone impersonate a provider if they could find a SHA1
collision for the provider?
-- same section, bullet starting with " check what virus typologies..."
I don't understand this paragraph--how can it know about viruses it didn't
detect?
-- section 2.2.4:
Are the details of this storage specified somewhere? How is it accessed?
-- section 3.1.2, first paragraph:
I'm confused--this seems to say that a message that exceeds the size limit will
get a non-acceptance notification, unless the message exceeds the size limit?
Are there 2 limits here?
-- section 3.1.4:
Does the acceptance notification imply the message has been _successfully_
forwarded to the recipients? I.e. does the AP need to delay acceptance
notification until it has successfully handed off the message to the downstream
MTA for each recipient? What if some fail and some succeed? (I suspect the
answer is no--in which case the text should say something like "…will be
forwarded…" instead of "has been forwarded")
-- section 3.1.5:
What is the root MIME type for a PEC envelope?
-- section 3.2.1, Paragraph 2: "The header of a take in charge PEC notification
contains the
following fields:"
Is it _limited_ to those fields?
-- same section, notification body:
I assume the listed recipients are only those for which the receiving point has
taken responsibility, right? That is, not necessarily the same as the original
recipient list? If so, it would help to clarify this.
-- section 3.3.2.2:
I find this entire section confusing, as it seems to mix general processing
requirements with requirements specific to S/MIME source documents.
How does the sending user request brief delivery notifications? I see how the
access point puts a the value in the PEC envelope, but that doesn't give the
sender himself a way to request it, does it? Also, is there a normative
requirement for the delivery point to honor "X-TipoRicevuta: breve"?
Also, I'm concerned about any new protocol that uses SHA1 without offering an
extensibility mechanism for integrating more modern hash algorithms.
-- same section, 2nd paragraph: "The brief delivery PEC notification contains
the original
message and a ciphered hash value of each attachment."
Please clarify what you mean by "original message". Were the attachments not
part of the original message?
-- same section, paragraph starting with " When the original message has an
S/MIME format, it is necessary
not to alter the integrity of the message structure."
Should that be a normative statement that PEC elements MUST NOT...
-- same section, last paragraph:
Where, specifically, is the filename to which ".hash" is added?
-- Section 3.3.2.3, first paragraph:
Do you really mean to send this to the recipients, rather than the sender? Is
that different than for the full and brief versions?
-- section 3.4: "PEC messages MUST be processed even if both sender and
receiver(s)
belong to the same PEC domain."
Even take-in-charge?
-- section 4.2:
Can you include an ABNF or other spec for date/time? Does this use a
preexisting format that can be referenced? (and if not, why?)
-- section 4.3.1:
Please clarify--these restrictions are only for bodies of messages generated by
PEC elements? I.e. these restrictions do not apply to the original message body?
-- section 4.5, first paragraph:
The process of downloading LDIF files into the master directory seem
underspecified. How long does the provider need to host the LDIF file? Will the
central directory try to download it more than once? How are errors handled?
Are there privacy concerns for the LDIF files?
Do I understand correctly that there's up to a 2 day delay before a PEC domain
learns about changes in another domain's directory entry?
-- same section, 2nd paragraph:
What is a "secondary operating environment? How are they used?
-- section 5.1:
The use of hardware crypto acceleration is an implementation detail--why does
it need to be in the spec?
-- section 5.2, first paragraph
I suspect the sense of this is reversed--did you mean to say the user MUST be
authenticated before he can access PEC services? Or is the intend really to say
a PEC provider cannot deny services to authenticated users?
-- section 5.3, third paragraph:
This seems to say that the incoming point MUST accept ordinary mail over
unprotected channels. Did you really mean that as a _requirement_?
-- same section, 4th paragraph: "To guarantee complete traceability in the flow
of PEC messages,
these MUST NOT transit on systems external to the PEC circuit."
Can you elaborate on what procedures providers must follow to achieve this?
-- section 5.5, general:
Are there really no requirements concerning certificate authorities and
certificate validation? It may be that the various PKCS and S/MIME docs specify
this sufficiently--but it would be worth a mention to that effect.
-- section 5.6:
This implies a requirement for TLS mutual authentication, right? This should be
mentioned explicitly.
ALso, do you assume any relationship between TLS certs and S/MIME certs for a
provider? Is the cert hash in the directory expected to also match the TLS
cert?
-- section 7:
I think you need more meat here, since this is fundamentally a security
protocol. What are the potential attacks on the system? How can they be
mitigated? Are there known weaknesses?
-- references:
I didn't find a reference for the document(s) that this is based on--is it
possible to add?
-- IANA considerations:
This draft specifies several new header fields. Do those not require IANA
registration?
Nits/editorial comments:
-- General terminology:
There are a lot of references to the "user", the "system", etc that are rather
vague as to _which_ user or system. I think it would be helpful to globally
change those to things like "sender", "recipient", "access point", etc.
-- section 2.1, paragraph 6: "...systems
MUST abide by the profile found in section 6.5."
Is that section 6.5 of this document, or 6.5 of [SMIMEV3]?
-- Section 2.1.1.1
s/"They"/"PEC notifications"
-- section 2.1.1.1.1, first paragraph
First sentence is a fragment. This pattern occurs quite a bit through the
document. Keep in mind the section title is not part of the sentence, or even
an antecedent for an upcoming pronoun--the body text should still stand alone.
-- section 2.2.1, paragraph 6:
s/typology/type. (same for other occurrences of "typology" elsewhere in the
doc.)
-- section 2.2.2, first paragraph:
s/"This point"/"The incoming point"
s/"inserted within"/"inserted into"
-- section 2.2.5, first paragraph, first sentence:
Sentence fragment.
-- section 3.1.5, 2nd to last paragraph
Can you provide an internal reference to "… what has been said regarding the
Message ID"?
-- section 3.1.6:
The bullet list at end of section seems mostly redundant with opening paragraph.
-- section 4.5, end of paragraph 1:
Is "HAVE TO" intended as normative? That's not defined in RFC 2119. I suggest
"MUST".
-- section 5.1
is "It is suggested..." meant to be a normative "it is RECOMMENDED…"?
-- section 5.5, first paragraph:
s/done/sent
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf