Comment on draft-arnold-scmp-02.txt

[John Stracke <[e-mail]>]

Some comments on draft-arnold-scmp-02.txt:

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".

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|[e-mail]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/