Subject: Comment on draft-arnold-scmp-02.txt

From: John Stracke <[email-masked]>
Date: Tue, 04 May 1999 15:48:53 +0000

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  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: Jason Eaton <[email-masked]>
Date: Tue, 04 May 1999 11:12:08 -0700

John thanks for the comments. Below are my attempts to answer them. Please
let me know if your questions aren't answered to your satisfaction.

>messages back and forth by S/MIME".

The introduction was meant to state the problem space this protocol solves.
I will re-evaluate the introduction and try to clarify.

We need this protocol to send "real-time" S/MIME messages from client to
server and back again. We are currently using this message protocol for
E-Commerce type messages that need encryption and signatures.

Can you clarify on "wide-open"? If you mean that the payload is not
specified, that was intentional. We don't restrict the implementations of
this protocol to a specific payload format just as S/MIME doesn't specify
it's payload.

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

Sorry, we will make that change.

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

We should add the requirement that this value be unique to the spec. 

>reach the server, you can't set the TTL reasonably.

If the TTL to live value is not obtainable we want the option to move the
message into batch mode. In that case we wouldn't throw away the message.

We could loosen up the MUST to MAY.

>message types out of their own domain space.

We don't want to specify the payload. As we use the protocol for serveral
different payloads.
I think that if we insist on specifying the payload that we should modify
the problem space that this protocol solves to more generic like S/MIME.
Changing the protocol from SCMP, to Real-time S/MIME or something along
those lines where the space that this protocol uses is not specified. If
that spec was changed in that manner then we wouldn't have to specify the
payload. ( like S/MIME )

>CA.  Why can't they just agree that one or both of them will run their

This needs to be loosened. It just needs to be a mutually trusted CA. It
doesn't matter if it's public or not.

>response or connect back to the sender's HTTP server.

Agreed. I will make this more clear. As far as overloaded POST ... ( shrug )

>harder); but section 2, paragraph 2 mandates that the server still

Ah, good question. We need to support non-repudiation. We cannot do this
with the current implementation of SSL. Additionally we need to support a
"static" message transport mechanism, ( like floppy disk, FTP ), we cannot
do this with SSL. In short we want the security to be applied to the
message not the transport mechanism.

Implementations can use SSL as well as SCMP. But to be an SCMP server you
must support S/MIME.

>7.1.1: do you have a reference for Secure NTP?

I check on that. 

>here are policy rather than protocol.

Should we not specify policy?

>body part that specifies these parameters.)

Yes we thought of supporting this. Part of the problem is that we have a
working implementation of this here at CyberSource now. We are processing
1-2 million transactions a month with it, over 200-300 merchants. Therefore
the development work involved in making our implementation spec compliant,
and updating all of our merchants for this case would be pretty costly.

I know this is a business excuse, but I think with this version of the spec
we can live without multi-part message support. Can we save it for the next
version?

>requests and think they've both been executed.  

A buggy client could make this assumption. Should a spec address buggy
clients? As long as the spec is clear on what the proper way to handle the
situation isn't that good enough?

> Third, it permits replay

I will re-evaluate this requirement with the other authors and see if we
can pull it out.

>8.1: can this format support Unicode error messages?

I don't see how the spec would not allow this.

>consistency"--that's "ensure".  Likewise in the first paragraph of

Thanks.

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

DOH!

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

( sigh )

Thanks for your comments, please reply if we have not addressed your comments.

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

---

From: Jason Eaton <[email-masked]>
Date: Tue, 04 May 1999 11:12:08 -0700

I check on that. 

Thanks.

DOH!

( sigh )

---

From: John Stracke <[email-masked]>
Date: Thu, 06 May 1999 14:22:52 +0000

These responses make a lot clearer to me.  In particular, I hadn't realized that
this was a pre-existing protocol.

I would suggest that, rather than issuing this version as a standards-track RFC,
it may be better to issue it as an Informational and start work on a
standards-track version.

Jason Eaton wrote:

> specified, that was intentional.

Yes, that was the problem.

> message into batch mode.

Um...OK.  I'm not sure why you'd want to do that, though.  Can you give me a use
case, please?

It would probably be best to clarify this in the draft, which doesn't currently
mention batch mode at all.

> We don't want to specify the payload. As we use the protocol for serveral

OK, understood; I just think that, if SCMP were adopted as a standard, the
payloads would have to be specified in standards documents, or you wouldn't have
any interoperability without private agreements (which don't scale, which is the
problem that standards are meant to address :-).

> Agreed. I will make this more clear. As far as overloaded POST ... ( shrug )

Yah, I probably wouldn't have mentioned that one if I hadn't been commenting on
the section already.  (Mind you, if this actually became a standard, I would
prefer to see a new method.)

> with the current implementation of SSL.

Really? SSLv3 supports client-side certificates; isn't that enough?

> Additionally we need to support a
> do this with SSL.

Huh.  OK, I can see that.

> Should we not specify policy?

I would think not.  You may want to make recommendations, probably in the
Security Considerations section; but my opinion is that you should not mandate
anything that does not directly relate to the protocol.  Security protocols are
fine--you can't have a policy saying "everything should be encrypted" if you
don't have a standard encryption protocol--but mandating how they are
administered is another matter.

> working implementation of this here at CyberSource now.

Ah, I see.  That was not apparent when I read the draft; and, yes, that makes a
big difference.

> we can live without multi-part message support. Can we save it for the next

Fine.

> clients?

Yes, because they're unavoidable.  Consider a client that sends a request and
then suffers a hard disk crash; after being restored from backup, it doesn't
remember which request IDs it's sent, and sends some duplicates.

> I don't see how the spec would not allow this.

But it doesn't support it, either.  You say that an error response is
"SCMP <error code> <error message>"; but you don't specify its MIME type or
whether it can carry charset and language parameters.

My feeling is that this may be a useful protocol, but we should

---

From: John Stracke <[email-masked]>
Date: Thu, 06 May 1999 14:22:52 +0000

Huh.  OK, I can see that.

Fine.