W3C home > Mailing lists > Public > xml-encryption@w3.org > April 2002

RE: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

From: Blair Dillaway <blaird@microsoft.com>
Date: Fri, 5 Apr 2002 12:57:00 -0800
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCF7D@red-msg-01.redmond.corp.microsoft.com>
To: "Tom Gindin" <tgindin@us.ibm.com>
Cc: <xml-encryption@w3.org>
I agree with you. Alg substitution isn't a very useful attack on XML Enc
or XML Sig with the algorithms defined in the spec.  If one used some
other algorithms, then it might be an issue for Sig.  Though, one might
question the wisdom of using a signature alg open to this type of
attack.

Blair
  

-----Original Message-----
From: Tom Gindin [mailto:tgindin@us.ibm.com] 
Sent: Friday, April 05, 2002 12:49 PM
To: Blair Dillaway
Cc: xml-encryption@w3.org
Subject: Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig



      I don't think that XMLEncryption is vulnerable to algorithm
substitution in the same way as XMLSignature can be.  Has anyone ever
seen an attack that substituted algorithms (or even keys) and produced
valid plaintext from the same ciphertext?  The argument for making
SignatureMethod optional is different than this - it's that for some key
types it's redundant (notably DSA) and the algorithm substitution
attacks don't work against PKCS#1 1.5 mode.

            Tom Gindin

"Blair Dillaway" <blaird@microsoft.com>@w3.org on 04/05/2002 12:34:54 PM

Sent by:    xml-encryption-request@w3.org


To:    <xml-encryption@w3.org>
cc:
Subject:    Re: EncryptionMethod in XMLEnc and SignatureMethod in
XMLDSig


While it might be nice to have a consistent treatment of
EncryptionMethod and SignatureMethod in the schemas, I think its more
important to have stable specifications for XML Signature and XML
Encryption at this point. So I am not in favor of changing the schema
for either of these elements.


I do agree with Merlin's argument about fragility of signed or encrypted
documents when the algorithms are omitted. I expect most applications
will include the xxxMethod element to explicitly identify the algorithm.
Still, there are folks who will use these for applications (like
messaging
systems) where they will be concerned about how many bytes of overhead
are required. So I lean toward having these be optional.


Blair


------------------------------------------------------------------------
------------------------------------------------------------------------
-----
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: Karel Wouters <Karel.Wouters@esat.kuleuven.ac.be>, Aleksey Sanin <
aleksey@aleksey.com>, xml-encryption@w3.org
From: merlin <merlin@baltimore.ie>
Date: Tue, 02 Apr 2002 16:59:25 +0100
Message-Id: <20020402155925.86ABB43BEA@yog-sothoth.ie.baltimore.com>
Subject: Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig


[ I believe I mis-sent the last copy of this. ]

The attack is to break a message digest algorithm, and to replace the
signed data with text indicating that the broken digest is to be used,
such that the new signed data under the broken message digest algorithm
has the same hash as the original signed data under the original message
digest algorithm. If the digest algorithm isn't in the signed text, just
change its setting in the appropriate place; possibly the application's
configuration file.

This isn't practical against DSA because its use of SHA-1 is currently
fixed.

Under RSA, the solution (that we also inherit) is to include the
signature OID within the RSA ciphertext. The attacker cannot replace
this instance of the algorithm specifier, and so this attack will be
readily apparent.

Given our current signature algorithm support, SignatureMethod may
safely be omitted. However, the dsig spec is beyond change so a
discussion to make it optional is somewhat fruitless.

Personally, I don't see the benefit of the optionality of these
algorithm identifiers. It doesn't seriously save much space, it doesn't
add security, it makes the long-term durability of documents much more
fragile, and it makes it more difficult to design a friendly API that
exposes the full capabilities of the specification.

Merlin

r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.04.02/15:39:21
>Hi Karel,
>
>but this attack is always possible, isn't it? If the verifying 
>application

>allows (accepts) weak signature methods, an attacker can change the 
>ds:SignatureMethod/@Algorithm value and the ds:SignatureValue . This
attack
>does not depend on whether the SignatureMethod is optional or not.
>
>Or am I completely on the wrong track.
>
>Regards,
>Christian
>
>--On Dienstag, 2. April 2002 16:00 +0200 Karel Wouters 
><Karel.Wouters@esat.kuleuven.ac.be> wrote:
>
>> Hi,
>>
>> I think that SignatureMethod in ds:SignedInfo should be present in 
>> each signature, because it restricts the attacker: If I leave out 
>> SignatureMethod, the attacker might be able to come up
with
>> a weaker SignatureMethod, tamper with the references and claim that 
>> the signature was produced with this method. RSA with a weak hash 
>> algorithm would suffice. (actually, he might produce 'any' signature 
>> if the hash function is weak
>> enough)
>>
>> So specifying the SignatureMethod ensures the verifier that this
signature
>> is generated with a solid technique.
>>
>> (mailinglist, correct me if I'm wrong)
>>
>> Karel.
>>
>> On Mon, 1 Apr 2002, Aleksey Sanin wrote:
>>
>>> Sorry for mistype, actually Imeant SignatureMethod in XMLDSig:
>>>
>>> A minor issue but probably it's worth to fix it: the 
>>> EncryptionMethod in XMLEncryption and SignatureMethod in XMLDSig 
>>> both have the same
>>> meaning: algorithm selection. However, EncryptionMethod is
*optional*
>>> element and SignatureMethod is *required*. From my point of view it
is
>>> inconsistent. Either both should be required or both should be
optional.
>>> I would prefer the second (both optional) since application can have
this
>>> information from the context.
>>>
>>>
>>> Aleksey Sanin <aleksey@aleksey.com> http://www.aleksey.com/xmlsec
Received on Friday, 5 April 2002 15:57:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC