Re: Security

I was unaware that it had been made semi-official, however it also has some
failings, most importantly there is no way to negotiate a suite of ciphers
to be used (when possible), this will necessitate the same mass reduction as
happened in S/MIME, there will become a de facto standard that is generally
weak. Additionally much of the information is based not on strong
cryptographic knowledge, but instead on the decisions made XMLEnc before I
explained what encryption is (which I did to several members), this results
in the need to have 3 layers of parsing, one for encryption, then signature,
then the SOAP parsing (in fact to the best of my knowledge I'm still the
only cryptanalyst involved in any way with the group). The design requires
exponential design decisions, requiring seperate code parsing for 3des-ecb,
3des-cbc, etc which can be a major drain on resources. The padding that is
encouraged is far from optimal from a security or space standpoint.
Hopefully the XML-Enc spec will have some very significant changes.

However the most important change that needs to be made is that the
extensions as they stand are themselves a weak use of cryptography, they are
an afterthought of the design, and completely inacceptable for protection
against future attacks. The compute overhead is also rather high, with an
integrity verified document requiring at minimum 2 public key operations,
and potentially a very large number of them (as many as 1+ 1 per encrypted
field), this can be lowered to a single public key operation, or 2 if a
signature is required for authorization (this ia already in the process of
being changed). I will of course be making my own proposal(s) that will
attempt to remedy at least some of these problems, but for now that is how
it stands.
                        Joe

----- Original Message -----
From: "Clemens F. Vasters" <clemensv@newtelligence.com>
To: "Joseph Ashwood" <jashwood@arcot.com>; <xml-dist-app@w3.org>
Sent: Thursday, March 15, 2001 3:13 PM
Subject: RE: Security


> Hi Joseph,
>
> pardon me for jumping in out of the void (since I am really only
> watching this list), and I am really only responding to this particular
> message from you, so I may be entirely off the mark here:
>
> I think that what Satoshi Hada and Hiroshi Maruyama from IBM Research in
> Tokyo are working on (and has partly submitted to the W3C) by using PKI
> signatures and PKI based encryption through SOAP header extensions
> sounds like a good solution for both authentication and privacy with
> protocols that are loosely coupled or essentially one-way and will not
> allow negotiation. (Applies to both, RPC and messaging)
>
> ( http://www.trl.ibm.com/projects/xml/soap/wp/wp.html)
>
> I understand that mandating PKI for XML protocol authentication may not
> meet the "simplicity" requirements, but when we're talking security for
> scenarios where you have no immediate connection between sender and
> recipient (this is also true for intermediate hops on synchronous
> links), I don't see any better way than using certificates to guarantee
> authenticity of messages. When you take that road, privacy protection
> comes more or less automatically with it.
>
> Regards,
> Clemens
>
>
>
> -----Original Message-----
> From: Joseph Ashwood
> Sent: Thu 3/15/2001 11:31 PM
> To: xml-dist-app@w3.org
> Cc:
> Subject: Security
>
>
>
> This conversation pretty much started on the SOAP list but I
> think it's far
> more applicable here.
>
> To give a quick summary of what has happened so far:
> There are no encryption/integrity methods that are really
> suitable for
> remote procedure calls. So it has been suggested that progress
> be made in
> that direction. This stems from a requirement for burst-type
> communications
> (commonly done over SMTP for SOAP), where negotiations are
> difficult.
>
> I was going to look into this some but I'm not sure what
> requirements people
> are likely to have. Do you want enough rope to be able to hang
> yourself very
> thoroughly? Or do you want strong guidelines that will limit
> diversity, but
> give you only solutions that are strong?
>
> What suitable compromises do you want to see? Do you want only a
> small
> number of ciphers , MAC, etc, that are secure and freely
> available? or do
> you want to be able to put your own prefered ciphers to use with
> minimal
> trouble?
>
> Any input would be greatly appreciated.
>                 Joe
>
>
>
>

Received on Thursday, 15 March 2001 19:07:03 UTC