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

[Jason Eaton <[e-mail]>]

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.

At 03:48 PM 5/4/99, John Stracke wrote:
>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".

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

Sorry, we will make that change.

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

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

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

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.

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

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 )

>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?

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

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

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

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

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. 

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

Should we not specify policy?

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

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?

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

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

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.

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

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.

>/=============================================================\
>|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 |
>\=============================================================/



Jason Eaton			CyberSource Corporation
Phone [phone]		Security Engineering Manager
[e-mail]	http://www.cybersource.com