RE: TRP Error Handling Spec Draft

[Dick Brooks <dick@8760.com>]

Just a couple of points regarding digital signatures:

- Some industry groups require digital signatures (both PGP and S/MIME) on
documents, it is imperative that they be fully supported in ebXML.
- A DoS attack can occur if there are no access controls on the E-Commerce
server (SMTP for example).
- A DoS attack involving crypto functions is less likely when access
controls are in place

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Wednesday, September 06, 2000 10:34 AM
> To: Burdett, David
> Cc: ebXML Transport (E-mail)
> Subject: Re: TRP Error Handling Spec Draft
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> David,
>
> A valid signature is as worthless as the bits which encode it.
> The only way that a signature can be trusted is in the case where
> a prior trust agreement has been established between the two
> parties:
>
> i.e. party A has a degree of confidence that party B has
> adequate safeguards over the protection of the certificate
> and its associated keys such that they are *less* likely
> to be compromised.
>
> There must also be some degree of assuredness that party B
> is in fact who they claim to be by virtue of the credentials
> which the CA required that party B present to prove that it
> was indeed party B and not some imposter. AND, by virtue of
> the trust with which party A has in the CA to safeguard
> its own keys, etc.
>
> I might add that the mere act of validating a signature/certificate
> is quite an intensive operation. A DoS attacker could exploit this
> fact quite easily, IMHO.
>
> Cheers,
>
> Chris
>
> "Burdett, David" wrote:
> >
> > Chris said ...
> >
> > >>>This establishes a nice DoS attack potential which is why I firmly
> > believe that it IS something which you want to agree to in advance
> > between the parties.<<<
> >
> > I agree. Although actually I think there is a similar, but
> worse, DoS attack
> > that we won't be able to easily avoid. As the following use
> case describes
> > ...
> >
> > In this use case on party is sending ebXML messages to another without a
> > prior TPA (see my second use case on party discovery for the full
> > explanation). In this use case:
> > 1. A buyer is sending a purchase order to a supplier that
> should result in
> > ...
> > 2. The supplier sending a purchase order response back to the buyer, and
> > later ...
> > 3. The supplier sending the goods to the buyer.
> >
> > This is a common method of wanting to do business.
> >
> > The Denial of Service attack would consist of a rogue server setting up
> > programs (along the lines of the recent "ping" attack on AOL & Yahoo and
> > others) that sent purchase order requests rapidly to the same
> supplier. If
> > the buyers are set up on a publicly available registry then
> getting buyer
> > information should be easy to do so generating different Purchase Order
> > documents from different buyers would be easy.
> >
> > Now I propose that we do not want to prevent spontaneous e-commerce
> > therefore the only way I see to get around this problem is for
> the recipient
> > of a message to validate its authenticity by checking a digital
> signature on
> > the document.
> >
> > Now if we are checking signatures to get around this problem
> then we should
> > be able to assume that the ErrorLogLocn is valid and therefore should be
> > processed.
> >
> > David
> >
> > -----Original Message-----
> > From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Thursday, August 31, 2000 4:19 PM
> > To: ebXML Transport (E-mail)
> > Subject: Re: TRP Error Handling Spec Draft
> >
> > Marty/David,
> >
> > See below.
> >
> > Chris
> >
> > David Burdett wrote:
> > >
> > > I think it is best if it goes in the header, since not
> recognizing the TPA
> > > id might be the error you are trying to report ;)
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> > > Sent: Wednesday, August 30, 2000 8:04 AM
> > > To: David Burdett
> > > Cc: ebXML Transport (E-mail)
> > > Subject: RE: TRP Error Handling Spec Draft
> > >
> > > David,
> > >
> > > When I got down to the end of my comments, it occurred to me
> that if the
> > > specification defined the format and content of the error
> information but
> > > limited itself to saying that the information should be
> logged such that
> > > both parties could have access to it, that would be a good
> thing. I think
> > I
> > > was more worried about how to fit the error messages into the
> protocol,
> > > where they should be directed to, etc., than about the contents of the
> > > messages.
> > >
> > > ErrorLogLocn could go in the ebxml header, to define the
> location to which
> > > a message about an error detected by a recipient should be sent.
> > > Alternatively, it could go in the partner profile and TPA.  I guess in
> > this
> > > case, the ebxml header makes more sense since it isn't an item that
> > > requires agreement.
> >
> > This establishes a nice DoS attack potential which is why I firmly
> > believe that it IS something which you want to agree to in advance
> > between the parties.
> >
> > >
> > > Regards,
> > > Marty
> > >
> > >
> >
> ******************************************************************
> **********
> > > *********
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
> ******************************************************************
> **********
> > > *********
> > >
> > > David Burdett <david.burdett@commerceone.com> on 08/28/2000
> 05:27:23 PM
> > >
> > > To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> > > cc:
> > > Subject:  RE: TRP Error Handling Spec Draft
> > >
> > > Marty
> > >
> > > We do want to keep it simple, however the S/390 environment where
> > > everything
> > > was under IBM's control is different from the ebXML
> envronment where the
> > > operating environment will by much more anarchical. So let's
> look at some
> > > of
> > > the issues ...
> > >
> > > 1. Development by many different vendors - if a vendor is not
> told what
> > > errors his software is generating he won't fix them at all or
> not until
> > > much
> > > later.
> > > 2. Used by SME's and the mega-corporation - this means that
> we need a way
> > > for SME's to easily report their problems and get them fixed.
> > >
> > > We actually thought about this when developing IOTP and one
> of the things
> > > we
> > > included was an "ErrorLogNetLocn" (see below) for an extract from the
> > spec.
> > > The ideas was that you could specify a URL where errors found in the
> > > messages sent by a company could be sent to that company so
> that could fix
> > > them. In theory, this log location should only occur during
> testing as all
> > > software as we know is bug free in production ;)
> > >
> > > David
> > > ==============
> > > Extract from IOTP spoec ...
> > > ErrorLogNetLocn     Optional. This contains the net location that
> > Consumers
> > > should send IOTP Messages that contain Error Blocks with an Error
> > Component
> > > with the Severity attribute set to either:
> > > o HardError,
> > > o Warning but the Consumer decides to not continue with the
> transaction
> > > o TransientError and the transaction has subsequently timed out.
> > > This attribute:
> > > o must not be present when TradingRole is set to Consumer role,
> > > o must be present when TradingRole is set to Merchant,
> PaymentHandler or
> > > DeliveryHandler.
> > > The content of this attribute is dependent on the Transport
> Mechanism see
> > > the Transport Mechanism Supplement.
> > > The ErrorLogNetLocn can be used to send error messages to the software
> > > company or some other Organisation responsible for fixing
> problems in the
> > > software which sent the incoming message. See section 7.21.1 Error
> > > Processing Guidelines for more details.
> > >
> > > -----Original Message-----
> > > From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> > > Sent: Sunday, August 27, 2000 3:40 PM
> > > To: David Burdett
> > > Cc: ebXML Transport (E-mail)
> > > Subject: Re: TRP Error Handling Spec Draft
> > >
> > > This proposal is well thought-out and well described.
> > >
> > > My concerns mainly relate to the KISS principle.  Is this a level of
> > > complexity and detail that is really needed?  An alternative
> at the far
> > > other end of the spectrum is to simply log everything and rely on
> > > out-of-band communications for the messaging service instance which
> > > received the message in error to notify the messaging service instance
> > > which sent it.
> > >
> > > When I was working with the IBM Poughkeepsie architecture team on the
> > S/390
> > > fiber optic channels, we accumulated a long list of errors
> which we wanted
> > > reported in a response message.  The I/O engineers then
> informed us that
> > > they were not going to analyze all this information.  Rather,
> they would
> > > log the error condition and take the most drastic recovery
> action (called
> > > connection recovery) whatever the error condition.  The
> recovery action is
> > > simply to terminate the logical and physical connections between the
> > > channel and I/O device and let software retry. The principle they were
> > > operating on was KISS.  They said that ecovery function is the most
> > > difficult to test and debug.
> > >
> > > 2.1.2 Types of errors
> > >
> > > Line 21 (2nd bullet, 3rd subbullet):  Please add "of a previously sent
> > > message" to the end of the line.
> > >
> > > Following line 21:  What about a category of "an error in a
> document which
> > > is reporting an error"?
> > >
> > > 2.1.3 When to Generate Error Messages
> > >
> > > Line 30 (1st para.):   Please change "message in error" to "received
> > > message".
> > >
> > > Line 30 (1st para.):  Please change "a URL to send the message" to "an
> > > address to send the message".  If the communication protocol
> is other than
> > > HTTP, the address won't be a URL.
> > >
> > > NOTE:  The IBM tpaML proposal covers only retries of transport timeout
> > > errors and business-level errors.  Business-level errors are
> reported to
> > > the sending application using <ExceptionResponse> and a corresponding
> > > action at the other partner which receives the exception response.
> > >
> > > NOTE:  It is not clear where the errors covered in the error-handling
> > > proposal should be reported to.  They are conditions
> presumably caused by
> > > the sending message service instance and detected by the
> receiving message
> > > service instance.  We will need to define some kind of
> "catcher" for the
> > > error messages and define what the catcher is supposed to do.
> > >
> > > 2.2 .1 Communication Protocol Errors
> > >
> > > Line 55 (Editor's note): The KISS principle applies here.  I suggest
> > > retrying communication-level errors at the communication level and
> > > reporting all unrecoverable conditions to one place rather
> than defining a
> > > unique recovery for each communication-level error.  Aside from
> > simplifying
> > > the implementation, it will avoid the need to track the other
> standards
> > for
> > > additional error codes.  I speculate that the function to which these
> > > conditions are reported will simply log them and process all
> of them the
> > > same way.
> > >
> > > 2.2.2.1  Identifying the Error Reporting Location
> > >
> > > 1st paragraph, line 63:  Please change "a URL" to "a communication
> > > address".  The communication protocol will not necessarily be HTTP.
> > >
> > > Line 65, by reference:  The TPAId is always in the ebXML
> message header
> > >
> > > Line 66, by value:  Please replace "the URL" by "the communication
> > > address".
> > >
> > > Line 66, by value:  A header error will make the value of such a tag
> > > untrustworthy.  I suggest that we limit ourselves to "by
> reference" and
> > > "implicitly".
> > >
> > > Line 74-76 ("Even if the message in error..."): Determining the error
> > > reporting location is not a problem with either "by reference" or
> > > "implicitly".
> > >
> > > 2.2.2.2  Error Reporting Location is Identified
> > >
> > > Line 80-82 (Editor note): For communication errors, replacing an
> > > acknowledgment message by an error message is OK (example:
> HTTP). If the
> > > message is sent at the messaging service level, it is not
> clear where the
> > > error message should go.  Possibilities are:
> > >
> > >    All the way to the application (e.g. the exception
> response message in
> > >    tpaML).
> > >    Some messaging service management function that we haven't yet
> > >    considered.  I believe that this is the preferable
> approach for errors
> > >    in the header and envelope.
> > >
> > > 2.2.2.3  Error Reporting Location not Identified
> > >
> > > Line 84-86 (1st para.):  This is reporting the error at the transport
> > > level.
> > >
> > > Line 87, editor's note:  Specifying rules to apply to each transport
> > > requires defining the layer of function that invokes the transport
> > > protocol.
> > >
> > > Lines 90-91 (If a suitable return address is not identified):
>  This is my
> > > preferred approach for error processing in general.  If we define a
> > > messaging service management function, then the error
> information could be
> > > sent to the management function at the sender and logged
> there, as well as
> > > being logged at the recipient messaging service management function.
> > >
> > > 2.2.3 Transient Errors
> > >
> > > Line 92 (title):  Please change the title to "Recoverable
> Errors"  and use
> > > the term "Recoverable"  instead of "transient" throughout.
> "Recoverable"
> > > means that retry is recommended.  "Transient" means that the
> error did not
> > > recur, which can only be known after the retry succeeds.
> > >
> > > Lines 105-106 ("If the ebXML messaging Services is unable to
> respond..."):
> > > If the messaging service is unable to respond within the
> timeout period,
> > it
> > > is probably unable to send the message which says it is
> unable to respond.
> > >
> > > Line 107 (determining the timeout period):  The TPA is one place to
> > specify
> > > the timeouts.
> > >
> > > 2.3.2  ebXML Error Document
> > >
> > > Lines 136-137 (Editor's note, list item 2): Since correcting
> the errors
> > > will require human intervention, logging the error condition should be
> > > sufficient.  As noted above, the sender needs to be notified
> of the error
> > > condition.  This notification could be outside the scope of the
> > > specification.  Alternatively, the error message structure
> defined here
> > > could be used for that purpose as long as it is sent to a management
> > > function at the sender and does not require executing a protocol to
> > > evaluate the error message as part of the exchange of
> messages between the
> > > parties.
> > >
> > > Line 139-40 (list item 4):  I completely agree.
> > >
> > > 2.3.5 ebXML Error Document Type Definition
> > >
> > > Lines 256-258 (Editor's note): Standard practice that I am
> familiar with
> > is
> > > to terminate the operation on the first error detected and report only
> > that
> > > error.
> > >
> > > 2.4.2  Non-XML Document ERrors
> > >
> > > Lines 330 (MsgTooLarge), 332 (MIMEError), 333 (MimePartMiss), and 336
> > > (MimePartUnx):  These conditions appear to be
> application-level errors.
> > > These could be reported directly to the sending application using a
> > > mechanism like <ExceptionResponse> as defined in the tpaML proposal.
> > >
> > > Regards,
> > > Marty
> > >
> >
> ******************************************************************
> **********
> > >
> > > *********
> > >
> > > Martin W. Sachs
> > > IBM T. J. Watson Research Center
> > > P. O. B. 704
> > > Yorktown Hts, NY 10598
> > > 914-784-7287;  IBM tie line 863-7287
> > > Notes address:  Martin W Sachs/Watson/IBM
> > > Internet address:  mwsachs @ us.ibm.com
> > >
> >
> ******************************************************************
> **********
> > >
> > > *********
> > >
> > > David Burdett <david.burdett@commerceone.com> on 08/18/2000
> 08:17:19 PM
> > >
> > > To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> > > cc:
> > > Subject:  TRP Error Handling Spec Draft
> > >
> > > Folks
> > >
> > > I attach some light reading for the weekend. Alternatively
> called, the TRP
> > > Error Handling draft spec version 01 ;)
> > >
> > > David
> > >  <<ebXML TRP Error Handling draft 01.doc>>  <<ebXML TRP Error Handling
> > > draft
> > > 01.pdf>>
> > >
> > > Product Management, CommerceOne
> > > 4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
> > > Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599
> > > mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> >
> > --
> >     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
> >    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
> >   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
> >        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> > _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
>
> --
>     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
>    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903