RE: Reposted Comments on SCMP ( by Graham Klyne )

Bartley, thanks for the comments they are good. See below for response.

At 03:34 PM 5/28/99, bartley.o'[email protected] wrote:
>As this protocol is designed for sending financial information I would have 
>thought that privacy was of the utmost importance.
>
>I suggest that ALL the SCMP header fields should be encapsulated within an 
>encrypted MIME body part with nothing more than
>the minimum MIME headers required for delivery appearing outside the message 
>body. In particular, no message-id and no from.

It is expensive to decrypt a message to determine the sender. The
SCMP-sender-name header was added to allow the server to reject the message
before decryption. 

I would like to hear a case arguing that the SCMP-sender-name headers is
confidential. I am not certain how the sender name could compromise
security, as this information is obtainable elsewhere.

>
>The first thing a receiving agent should do is decrypt the incoming
message to 
>access the SCMP control fields and verify the signature.
>

This is stated in the draft.

>The MIME from field, the SCMP-sender-name and the digital signature all 
>contain 
>an identity. That is 3 names, all potentially different,
>in one message which is from one sending agent. I suggest that, as the 
>signature name is a legally enforceable identity, the other 
>two, from and SCMP-sender-name, are redundant and should be removed. (The
from 
>is only really needed to provide a human readable
>identity for mail applications.) 
>

We currently do not use the MIME "from field", however you are correct. It
is redundant. As far as which name to use, the only name that matters is
the name in the signature. If we retain these headers we should mention in
the draft which value is the definitive one.

>  >2.2 SCMP Sender Name
>  >
>  >The SCMP-sender-name header is used to designate the SCMP sender name.
>  >Thereby the sender name can be accessed before any decryption of the
>  >request is performed. Server implementations MAY reject the request
>  >based upon sender name, before any message processing occurs.
>Unless the SCMP Sender name is contained within a signed component it is very 
>dangerous to base any processing on it. A denial of 
>service attack could easily be mounted by simply corrupting the sender name, 
>causing rejection of all messages or unwanted processing
>by changing it to another valid name. 
>

Ahhh ... here is the argument I am looking for. Is there a better argument
for this then "denial of service" attack? The current transport protocols
do not account for denial of service. Currently we use HTTP as the
transport for SCMP, therefore denial of service can easily be accomplished
without corrupting the signature of the message.

>An easily readable name gives instant knowledge to an attacker of the 
>existence 
>of a relationship between the sender and receiver. Easily
>readable SCMP control fields further identifies the relationship as a 
>financial 
>one. Simply collecting this type of information and publishing
>a "Customer/Account holder List" could be very damaging to the public
image of 
>a financial organisation like a Bank.
>

Oops, another good argument for the remove of clear text headers. ( i
should have read your whole message thoroughly before replying ) 

I agree ... ok. However I am worried about performance characteristics of
this change. Anybody else have any opinions on this one?

>
>>7.7.2 Server Errors.
>
>If the SCMP control information includes a generation date and an expiry date 
>it will only be necessary to store message id's, to protect
>against replay, for a restricted period of time.
>
>If we are receiving financial transactions there will be a requirement to 
>store 
>them for a minimum period both for non-repudiation purposes and regulatory 
>requirements.
>

Storing the reply is necessary for the reasons you list, however the reply
mechanism that the draft contains is a "can of worms". I believe the
consensus is to remove the ability of the protocol to return a previously
sent reply and instead return an error.

>
>I'm getting on my soap box...
>
>An Inland Revenue letter looks like an inland revenue letter, a pin mailer 
>looks like a pin mailer and a court summons looks like a court summons, Our 
>postmen/women could probably tell a lot about our private lives from looking 
>at 
>the post we receive. In an ideal world ALL post would be sent in 12" cube 
>cardboard boxes and we would have privacy. In an ideal electronic world all 
>messages would be sent signed THEN encrypted with minimal routing information 
>only on the outside. In this way it would be impossible to determine any 
>information about the message.

Bartley, the draft recommends the use of signed/enveloped. Are you
proposing that we make it a MUST and also remove the signed only
requirement as well?

Cheers.

>
>
>Regards,
>Bartley.
>
>Bartley O'Malley
>Citibank NA
>Lewisham House
>25 Molesworth Street
>London
>SE13 7EX
>England
>
>Tel +44-171-500-6473
>Fax +44-171-500-8880
>
>


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