Reposted Comments on SCMP

Submitted by John Stracke, on 5/4/99:

  First, I'm not sure what problem this protocol is meant to solve.  It's
  so wide-open that it defines scarcely more functionality than "send
  messages back and forth by S/MIME".

  2.1: You need to specify a protocol version for this version of the
  protocol.

  2.2: You need to make sure the sender name is globally unique--e.g., an
  email address.

  3.1: I'm dubious about the utility of the time-to-live field--how often
  do you have an operation that you don't want to do at all if you can't
  do it in N seconds? I suppose it might come up sometimes, but certainly
  not every time--and TTL, like all these headers, is a MUST.  Further,
  since you can't tell how long it's going to take for the message to
  reach the server, you can't set the TTL reasonably.

  3.2: The message type needs some more structure if there's to be any
  sort of interoperability.  Private agreements aren't good enough; what
  happens if companies A and B use the term CommerceService one way, C and
  D use it another way, and then A starts doing business with C? The
  cleanest way is probably to use URIs, so that a company can make up
  message types out of their own domain space.

  5: you mandate that the partners get their certificates from a public
  CA.  Why can't they just agree that one or both of them will run their
  own CA?

  6: your HTTP mechanism uses POST, which is already the most heavily
  overloaded method in HTTP.  You also should specify whether the SCMP
  server would return the SCMP reply as the entity-body of the HTTP
  response or connect back to the sender's HTTP server.

  Also, if you're using HTTP, why not run it over SSL/TLS instead of
  encrypting the message with S/MIME? It'll give you better security
  (since it eliminates the cleartext MIME headers, making traffic analysis
  harder); but section 2, paragraph 2 mandates that the server still
  implement S/MIME.

  7.1.1: do you have a reference for Secure NTP?

  7.1.2: it seems to me that the mechanisms described in the subsections
  here are policy rather than protocol.

  7.2.1: since serialization is probably an important feature (without it,
  you can't do pipelining), why not specify it? It'd be pretty easy:
  specify that a server which receives an SCMP request of type
  multipart/mixed MUST treat it as separate requests which MUST be
  processed in the order in which they appear in the multipart, and send a
  reply of type multipart/mixed, where the Nth body part is the reply to
  the Nth request.  (You'll need some parameters related to error
  processing [do  you execute the second request if the first request
  fails?] and atomicity [do you rollback the first request if the second
  request fails?]; maybe it should be a multipart/related, with a root
  body part that specifies these parameters.)
  
  7.2.2: the requirement to replay the prior reply when a duplicate
  request is received is problematic.  First, it requires the server to
  store all replies indefinitely.  Second, it means that a buggy client
  which generates the same request ID twice may submit two distinct
  requests and think they've both been executed.  Third, it permits replay
  attacks: if C has sniffed the traffic between A and B, and has hijacked
  A's incoming SCMP replies, C can resubmit a prior request N times and
  get the same reply encrypted N times; each one will be slightly
  different (since the reply will contain a timestamp), which will
  facilitate cracking the encryption key.  (This can also be a
  denial-of-service attack, since the server has to spend lots of CPU
  cycles on encrypting the text over and over.) I would recommend that
  duplicate requests generate an error.
  
  8.1: can this format support Unicode error messages?

  Spelling nits:

  3.1, the fourth paragraph starts, "Application functions to insure data
  consistency"--that's "ensure".  Likewise in the first paragraph of
  section 3.

  7.1.2.6: it's "revocation", not "revokation".

  7.2: "sender's certificate", not "senders certificate".


Jason Eaton			CyberSource Corporation
Phone 408.260.6044		Security Engineering Manager
[email protected]	http://www.cybersource.com