Re: EncryptionMethod in XMLEnc and SignatureMethod in XMLDSig

MessageSome thoughts off the top of my head...

If the choice of algorithm (whether digest, signature, or encryption) is important (as it ususally should be), then applications must include a check on the algorithm(s) used when asserting the result of validating a signature or decrypting data.  For example, if a signature's digests are valid, the signature value is valid but one or more algorithms used were not acceptable, the application must indicate the signature is not to be trusted.  (There's also the rules used to assess the validity of the verification public key but I won't discuss that here.)

I have trouble with the argument about an attack of changing an application's configuration file because if an attacker can change a core part of a cryptographic application then pretty much anything can happen.

Despite what I've just written, I'm comfortable with having the requirement for XML Signature's digest and signature algorithms to be explicitly stated.  After all, I'm not saying that there are not iron-clad arguments for requiring it, just that I'm not convinced by the ones presented.   Nonetheless, I feel safer on the side of over-specification.

But with regard to XML Encryption, I'm still comfortable with leaving the encryption algorithm is optional.  Yes, someone could use a weaker encryption algorithm than is required but ultimately the decrypting application has to know what algorithms are acceptable and reject unacceptable algorithms whether specified or not.  Yes, an attacker could substitute an <EncryptedData> element with a strong algorithm with a weaker one (over the same of different data), but could also just substitute the original <EncryptedData> with another <EncryptedData> using the same or another acceptable algorithm.  Unlike, signature validation there's not the same sense of validity of the result of the cryptographic operation.  If the decryption works, it works; it doesn't tell you about the trustworthiness of the data.  If integrity of the decrypted data is important, then it has to be protected with a signature.

Please respond if you think I'm mistaken anywhere.  

Regards, Ed
  ----- Original Message ----- 
  From: Blair Dillaway 
  To: xml-encryption@w3.org 
  Sent: Friday, April 05, 2002 12:34 PM
  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