RE: ID Tracker State Update Notice: draft-ietf-ediint-as2

>  what do I have to do?.... .anything? Hey thanks from all of 
> us for being an
> AD.... Imagine how much work it is... rik

Rik,

You can find all of the IESG review comments in the public I-D tracker:

https://datatracker.ietf.org/public/pidtracker.cgi

I've included them here for completeness.  All marked "Discuss" MUST be
addressed; those marked "Comment" SHOULD be addressed.  If you have any
questions about any of them you should contact the appropriate AD with
follow-up questions.  Each will have to review and approve any updates to
get the document to move forward.

-Scott-
----------
Harald Alvestrand:
Comment:
[2004-10-28] Reviewed by John Loughney, Gen-ART

His review:

Formatting problems are so severe, I'd recommend a revision before
considering
this draft.  The text is somewhat dense and hard to parse, so the formatting
problems really make this impossible to read.  I can try to re-read the
draft
for technical comments and will update this review if I find anything.

In summary, I'd issue a discuss on this because of formatting - I doubt this
passes
the ID-Nits.

John

Major
1) What is AS2?  This needs to be explained somewhere.

Questions
1) The introduction discusses the relationship of this draft to other EDI
RFCs.
  Does this document update / obsolete any of these RFCs? If so, it should
mention
  it explicitly.

Nits
1) Header & footer on page 1 should be removed.
2) Lots of editing problems - bullet lists should be reformatted, 
  sections should be left justified, blank lines should be inserted
  after section titles, ToC should list page numbers, bulleted lists
  have formatting problems (page 6, for example).

Steve Bellovin:
Discuss:
[2004-10-25] Nit: there are two sections numbered 1.1

Nit: in the second of those sections, there's text that speaks of MD5's
small key size.  MD5 is a hash algorithm and doesn't have keys.  I believe
what was meant is "short block size".  If possible, I'd leave MD5 out; if
you must leave it in, say that it SHOULD NOT be used except for
compatibility, because of cryptographic weaknesses in MD5.

4.1: "AS" is never expanded

There's no discussion of replay detection or prevention, nor of checking the
message date to see if it's stale.  I assume, from the text on reusing
Message-IDs, that they could function as replay detectors; in that case,
some notion of when a message is stale should be included, so that the list
of previously-seen Message-IDs can be pruned.

Ted Hardie:
Discuss:
[2004-10-25] I think the asynchronous MDNs text is confusing, and I think it
could be cleared up
fairly easily (at least I hope so!).  First, my understanding is that an
asynchronous
MDN is essentially any MDN which can be later correlated to the original
message.
As the document notes, this means that the MDN must contain enough  data
to ensure that it uniquely identifies the original message.

The document refers to RFC 3789 on MDNs, but it seems to
want only the definition of message/disposition-notification from that; even
in the case of SMTP-based asynchronous notifications, the document should
look to RFC 3355?  Are there other aspects of 3789 that are needed for this?
If not, can the limitation be clarified?

The diagram in 7.2 contains:

  Asynchronous AS2-MDN 
  [C] ----( connect )----> [S] 
  [C] -----( send )------> [S]  [HTTP Request [AS2-Message]] 
  [C] <---( receive )----- [S]  [HTTP Response] 
    
  [C]*<---( connect )----- [S] 
  [C] <--- ( send )------- [S]  [HTTP Request [AS2-MDN]] 
  [C] ----( receive )----> [S]  [HTTP Response] 
  * Note: An AS2-MDN may be directed to a different host than that of 
  the sender of the AS2 message and may utilize a different transfer 
  protocol than that used to send the original AS2 message. 

The server initiates an HTTP connection to the client?  I think this
actually confuses "client/server" roles with "party1/party2" roles.
If [S] is actually "party2", this makes sense, but [C]/"party1" must
be an HTTP server, capable of handling the HTTP Request.

An additional issue here is that the document doesn't seem to say
whether the HTTP Request [AS2-MDN] is sent via a POST request or
something else (e.g. PUT).  I think POST, but this should be clarified.

I'm also a bit concerned about how the mail-address in
Disposition-notification-to
is being treated.  If it MUST be present and MUST be ignored, why not give
it a specific address in .invalid or recommend addresses in .invalid for use
here?

Russ Housley:
Discuss:
[2004-10-27] 
  I find the signed receipt discussion confusing.  Sometimes, it seems
  that the signed receipt mechanism defined in RFC 2634 meets the needs
  of EDI and other times it appears that some EDI-specific content is
  needed.  In my opinion, the cryptographic binding provided by the
  mechanism in RFC 2634 is highly desirable.

  Section 1.1 says:
  :
  : Non-repudiation of receipt (NRR) - NRR is a "legal event" that occurs 
  : when the original sender of an signed EDI/EC interchange has verified 
  : the signed receipt coming back from the receiver. NRR IS NOT a 
  : functional or a technical message. 
  :
  This is not sufficient.  One must also match the values in the signed
  receipt against the retained copy of the original as is discussed in
  section 7.1.  Pointing out that the returned MIC value inside the MDN
  must be the same as the digest of the original message early in the
  document would greatly help the reader.

  Section 2.3.1, 1st bullet, says:
  :
  : -The organization sending EDI/EC data signs and encrypts the data    
  :  using S/MIME. In addition, the message will request a signed 
  :  receipt to be returned to the sender of the message. 
  :
  The sender must keep a copy of the original message or the message-id
  and digest value of the original message.  The receipt validation
  cannot be performed without these values.

  Section 2.3.1, 3rd paragraph says:
  :
  : The above describes functionality which, if implemented, will
  : satisfy all security requirements and implement nonrepudiation
  : of receipt for the exchange.
  :
  Section 1.1 says a signedReceipt is a receipt signed with a
  digital signature.  Then, section 7.4.3 says that a signed
  receipt does not have to include the Returned-content-MIC.
  Without the Returned-content-MIC NRR is unachievable.

  Section 2.3.2, 2nd paragraph, 2nd sentence says:
  :
  : NRR refers to a legal event which occurs only when the 
  : original sender of an interchange has verified the signed
  : receipt coming back from recipient of the message.
  :
  This is not sufficient.  I suggest:

    NRR refers to a legal event which occurs only when the
    original sender of an interchange has verified the
    signature on the signed receipt as coming from the
    recipient and the returned MIC value inside the MDN is
    the same as the digest of the original message.

  Section 2.4.2 says:
  :
  : If a signed receipt notification is requested however, a MIC value
  : is REQUIRED as part of the returned receipt, unless an error
  : condition occurs in which a MIC value cannot be returned.  In error
  : cases, an unsigned receipt or MDN SHOULD be returned with the
  : correct "disposition modifier" error value.
  :
  And, Section 7.3.1 says:
  :
  : When a request for a signed receipt is made, but there is an error
  : in processing the contents of the message, a signed receipt MUST
  : still be returned. The request for a signed receipt SHALL still be
  : honored, though the transaction itself may not be valid. The reason
  : for why the contents could not be processed MUST be set in the
  : "disposition-field".
  :
  These seem contradictory.  The first says that a MIC is not required
  if there is an error, but the second says that a signed receipt MUST
  be returned.

  Section 7.3.1 says:
  :
  : When a request for a signed receipt is made, the "Received-content-
  : MIC" MUST always be returned to the requester.
  :
  And, Section 7.4.3 says:
  :
  : This field [in reference to the Received-content-MIC] is set only
  : when the contents of the message are processed successfully.
  :
  These seem contradictory.  The first says that a MIC always returned,
  but the second says that the MIC is only returned if the processing
  is successful.

  The Security Considerations needs to cover addition topics:

  - The NRR service supported by this document relies on the
    originator retaining a copy of either the original message or
    the MIC of the original message.

  - This document allows for the return of signed receipt that does
    not fulfill the NRR service, that is a signed receipt can be
    returned without the Returned-content-MIC.

Comment:
[2004-10-27] 
  Please use include a hyphen in "non-repudiation" throughout the
  document. This is the accepted spelling when referring to the security
  service.

  In section 2.3.1, 3rd bullet: s/message,indicating/message, indicating/

  In section 2.4.2, Permutation Summary, please add the following options,
  as the previous paragraphs indicate that if an error occurs an unsigned
  receipt can be returned:

    1) Sender sends un-encrypted data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

    2) Sender sends encrypted data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

    3) Sender sends signed data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

    4) Sender sends encrypted and signed data, requests a signed receipt.
      Receiver sends back an unsigned receipt.

  In section 7.4.3: s/algorith/algorithm/

  In section 7.6: s/varydepending/vary depending/

  Please add a reference for S/MIME Version 3 Certificate Handling, it is
  referred to in Security Considerations.  I would like for this to be
  a normative reference, with the following text appearing in the
  beginning of the Security Considerations:

    The following are the additional security considerations to those
    listed in [4] and [X]:  The following certificate types MUST ...

  Where [X] refers to the S/MIME Version 3 Certificate Handling document.

Allison Mankin:
Comment:
[2004-10-28] The IANA registrations are very terse - they should say into
what registry they go.