[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EDIINT Requirements
Harald.T.Alvestrand@uninett.no wrote:
>
> >
> ---------------------------------------------------------------
> [NOTE: This note is NOT from me in the role of Applications AD.
> It's sent in my role as working group member, who wants to contribute
> to this WG by making sure its documents are as clear as possible,
> giving the clearest possible guidance to the Internet community.
> I hope to stimulate more discussion in the WG, so that the documents
> produced will be as good as possible before they come before the IESG
> for review.
>
> Remember - IETF documents are not the responsibility of their authors
> or WG chairs only; they are the responsibility of the WORKING GROUP.]
>
> I have read through the draft requirements document,
> draft-ietf-ediint-req-00.txt, and found it good.
>
> The structure seems well thought out, its recommendations mostly make
> sense, and most of its descriptions are clear.
>
> However, I have a number of issues that concern me, which
> I hope that the authors can clarify, and if necessary the WG can come
> to consensus on, before the next version of the document is issued.
>
> To start from the start of the document:
>
> - There needs to be an introduction that says WHAT the model is that
> the document is describing, and WHAT interfaces it is trying to
> make requirements for.
>
> My picture looks roughly like this:
>
>
> EDI system EDI system
> | ^
> A C
> v |
> Sending MUA--------B-----------> Recipient MUA
>
> where most of the requirements are on the "B" interface.
> But sometimes it touches on the "A" and "C" interfaces, which
> makes me wonder: do we really want to go there?
>
> The document should decide either to state all requirements for
> those interfaces, stay totally away from them, or explain why
> it needs to go into some details but not others.
>
I think that some of the A and C interfaces should be discussed, and
aspects of these interfaces are discussed in both the requirments and
the AS#1. I think the suggestion at the last IETF wg meeing to put
some of the implementation considerations into an appendix is a good
one, and the A and C interfaces and other considerations of implementa-
tion should be discussed in this appendix. Are you agreeable to this?
> Another problem is keeping the difference between a SPECIFICATION
> and an IMPLEMENTATION clear. The IETF clearly cannot, and MUST not,
> recommend a specific IMPLEMENTATION of a protocol or specification.
> So properties of IMPLEMENTATIONS are at best interesting to prove
> that something can be done, or is easily available in existing
> products. But the document has to recommend SPECIFICATIONS.
Question on this point: Is PGP considered an implementation or a
specification. In my mind it is an implementation and not a
specification.
Other than PGP are there any other implementations that are
referenced versus a specification?
>
> - The formatting needs work. In particular, an index doesn't help
> all that much when there are no page breaks in the document!
This will be fixed.
>
> Now into the niggling little details:
>
> - Section 1.0 Introduction:This section refers to a requirement to
> add stuff that mimic header fields from X.435. This requirement does
> not resurface in the rest of the document.
This is a remnant from a requirement that was brought up on the list
concerning gatewaying between the Internet and EDI VANs and internal
e-mail gateways that would like a more convenient way of routing
EDI when received from the Internet.
I think it was decided that this would be another work effort. Rik
knows what is going on here a bit better than I. The introduction
was trying to acknowledge that work should be done in this area,
but is not explicit in saying it would not be covered in the
requirements document.
>
> - Section 3.2.1: The description of the "strength" of a cryptoalgorithm
> is too simplistic. For instance, I think that the strength of the
> DES algorithm against a chosen plaintext attack is thought to be
> approximately equal to 54 bits, because the effort needed for a
> differential-cryptanalysis attack is on the same order as trying
> all keys of length 54 bits.
> Also, the strength of the RSA algorithm is not proportional to the
> length of its key, since its key is far from a random number; it
> has to be one function of its two generating primes; the effort needed
> to crack it corresponds to some lower number of bits.
> A cryptanalyst could give you more details here.
>
I'll forward this comment to Taher El Gamel, who is our chief scientist
here and will get it clarified.
> - Section 3.2.2: The description here assumes that symmetric keys are
> used for several exchanges. This makes confusing reading when the later
> (and IMHO correct) recommendation is that a symmetric key be used for
> only one exchange.
You are correct. I was trying to present an over-view of symmetric key
management and how you can evolve it using public key technology to
not just use one symmetric key but to generate one each interchange
exchange. I'll clarify.
>
> - Section 3.2.3: The description of signature is slightly wrong; the
> encrypted item is a checksum of the message, not "part of" the message.
Will change.
>
> - Section 3.2.6: I think it's wrong to say that the DES algorithm is
> "secure" by the definition from 3.2.1, not only because it's got a
> fixed key length. It would be more true to say that its strength is
> considered known: o(56 bits) for CBC mode without chosen plaintext.
>
"Secure" of course is a relative term. I will discuss that its strength
is considered known, but in many typical EDI transactions, DES is
"secure", enough.
> - Section 3.2.6, RC2 and RC4: There's a general weakness to these
> algorithms that if the same key/initialization vector is used to
> encrypt several items, some of which are known, the cipher can be
> easily broken. This was the basis for the Win95 "password saver"
> security hole. Do we want to go into that kind of detail?
>
This is a general question. Should we go into more detail on the
cryptographic aspects of some of the algorithms? Or should we refer
the reader to a reference that gets into the details? I think if we
start getting into too much detail on cryptography, it will be
either confusing, inaccurate, or both.
> - Section 3.3.1: Again, the unspoken assumption is that symmetric
> keys are used for several exchanges. It should be explicit.
>
Will clarify.
> - Section 3.3.3 "issues" seems to be a "recommendation", and
> section 3.3.4 "recommendation" seems completely out of place.
>
Will clarify.
> The text in section 3.3.4, which describes RSA, also needs to
> have added text about RSA's patent status in the US, what the
> key length means for RSA (as mentioned above, a 512-bit key doesn't
> have 512 bits of randomness) and strength. I think the text in
> section 3.3.4 belongs to the beginning of section 3.4.
Will clarify.
>
> - Section 3.4.2: Trading partners MAY exchange public keys using
> an X.509 certificate; mandating this doesn't belong in an
> "introduction" section. There are other methods, including PGP
> certificates and the PK source identifier from MOSS.
This section has been revised in the second revision.
The intent was not to mandate the use of X.509 certificates, the
document goes even furthur in allowing trading partners to self-certify,
which means they can exchange public keys in any manner that is
agreeable to the partners. I think that using X.509 certificates
even when self-certifying or some formal certificate exchange mechanism
is highly recommended. The trend especially for commerce, is to use
X.509 certificates, and the CAs that are now available do use X.509
certificates.
>
> - Section 3.4.4 assumes that a formal CA hierarchy is required for
> X.509 usage. This is by no means certain; X.509 can easily be used
> to support a web of trust along PGP-like lines. It may be the right
> decision, but needs to be made as a decision, not an assumption.
> (In fact, the recommendation is opposite)
Again this should be clarified in the second revision. I agree
especially in EDI, the PGP-like web of trust is a very good model
that can be used. Again the intent was not to specify a formal CA
hierarchy, self-certification (web of trust) is acceptable in EDI.
>
> - Section 3.5.1: The description of the MIC is confusing; it doesn't
> "turn the plain-text into something unintelligible", but computes
> a number that is a function of the plaintext; the plaintext continues
> to exist!
Will clarify this.
>
> Also, the claim that 2^-128 is equal to infinity is slightly amusing....
>
> - Section 3.5.4 ought to mention the names of some other algorithms.
> Possibly the SHA vs MD5 security debate should be listed under "issues".
This has been updated in the second revision, and the SHA vs MD5 debate
is discussed.
>
> - Section 3.6.4 should repeat the keylength recommendation for RSA.
>
> - Section 3.7.3, on the need for expanded functionality in a MDN,
> should simply say that the EDIINT group will take on a work item
> to develop the needed extensions to the MDN.
Will update to reflect these comments.
>
> - Section 3.8 seems to lack a Recommendations section; it's not
> clear what the purpose of the section is. it may need to be moved
> to the Introduction.
This has been revised in the second revision.
>
> - Section 3.9.4: The problem of several standards should be moved from
> Recommendations to Issues, with Recommendations saying:
> - Security multiparts are recommended
> - Either one of S/MIME or PGP/MIME appears to fulfil the
> requirements
> We should avoid most carefully mixing together PGP 3.0 (a product)
> with S/MIME and PGP/MIME (specifications); this document HAS to
> recommend specifications, and can use products only as examples
> to prove that a given specification has implementations.
This answers my question above on PGP. I will make it clear whether
we are dealing with a product or a spec, and make the context
appropriate.
>
> - Section 4.1 needs to mention RFC 1894 along with the other methods
> of "positive ack"
>
> - Section 4.2 and 4.3 are requirements on the EDI system/MUA interface.
> Is it appropriate to put these in this document?
>
> - There seems to be a missing section between 4.3 and 4.4 where
> "transmission succesfully delivered to recipient MUA" should go.
> The requirement MAY be a non-requirement ("we don't need this"), but
> this decision should be explicit.
These section have been revised to reflect "transmission successcully
delivered to recipient MUA". Again my inclination now is to move
these sections into the appendix where we discuss implementation.
(Where we will move portions of AS#1 to.)
>
> - Section 4.7, detection of duplicate transmissions, does not have
> a Recommendation. As this may be critical functionality, I think
> it should have: Content-MD5 comparision of transaction content.
I'll need to consider this one a bit more. The content-MD5 can be
used in this context, but do we want to specify it or just recommend
it as a way of implementing detection?
>
> - Appendix A is messy.
> First, it needs to specify:
> - That it's a comparision of PROTOCOLS, not PRODUCTS
> - Exactly what specifications it is comparing, by document, chapter
> and verse.
> (For instance, there's a critical difference between S/MIME and the
> others in signed messages that I hear has been repaired; it's IMPORTANT
> for readers to be able to tell if this refers to pre-repair S/MIME or
> post-repair S/MIME).
Yes, this issue is covered in the AS#1 on how S/MIME has "repaired"
signed messages. These sections as agreed at the IETF wg will be
moved to the requirements document appendix.
My real question here is whether we still want to include this
matrix in the requirements document, since it will change continuously
and need to be updated more frequently than the document itself.
Should we refer to the matrix from the document and maintain it
seperately?
>
> Secondly, it needs a section to specify what the documentation
> status for each spec is:
> - PGP 3.0 is not stabilized; PGP/MIME is approved I-D + RFC
> - MOSS is RFCs
> - S/MIME is (what?)
> - MSP is (what?)
This can be done.
>
> Thirdly, it should use at least 1 sentence per section to explain
> what the section title means; some (18 for instance) are nearly
> incomprehensible to me, while others, like 19 and 20, seem to
> me to be different variants of the same question, yet have
> different answers?
>
> - 4: Current implementation status does not distinguish between core
> implementations and "shells" that use the core; for PGP, I believe
> there is only one core, while Eudora, Premail and others provide
> wrappers around the core.
> S/MIME needs product names if we give it for the others.
>
> - 5: Confidentiality is messed up in formatting.
>
> - 7: the content is wrong - 1891-94 does NOT support return receipt.
This has been corrected in the second revision.
>
> - 17: Algorithms - this section is confusing; only PGP v3.0 (which isn't
> done yet) has key lengths, 2 of 3 have a "note" about algorithm
> independence after listing algorithms, while the 3rd is vice versa.
> Needs cleaning.
>
> - 22: Backwards compatibility: What does this mean?
> If products are able to read older versions, that's a product
> property.
> If some older standard is a true subset of the new standard, that
> would be a standards backward compatibility, but this is untrue
> of both S/MIME and MOSS, and likely to be untrue of PGP!
I'll need to clarify what the intent of this section is.
>
> - 27 and 28: MOSS is left blank. I don't like "don't knows", not when
> the question should be answerable by reading RFCs.
>
> - 29: Product requirement, not protocol. Needs justification.
>
> That should be all for this version!
>
> Harald A