RE: I-D ACTION:draft-ietf-smime-multisig-00.txt

["Turner, Sean P." <[e-mail]>]

Dennis,

Comments inline..

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: Tuesday, December 26, 2006 6:19 AM
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-multisig-00.txt


Comments on draft-ietf-smime-multisig-00.txt

..snip

However, this draft is unclear on how it applies. There are three types of
RPs concerned with this draft:

a)	RPs able to process "weak" algorithms, 
b)	RPs able to process "strong" algorithms only, and
c)	RPs able to process both "weak" and "strong" algorithms.

spt> The draft is intended to address all three types of RPs.

In case a, the main advantage of this draft is to allow to link digital
signatures from the same signer in case of algorithm migration. If the RP
decodes a SignerInfo with the "strong" algo, then it cannot verify the
digital signature, but then it can easily figure out that there is another
signature with the weak algorithms that it can process. The draft is silent
about this scenario.

spt> The main advantage of the draft is to allow you to know if an attacker
stripped off a SignerInfo.  I will add the point about being easier able to
find the other signature if you only support one of the two.

In case b, the RPs is only able to process strong algorithms. If the RP
decodes a SignerInfo with the "weak" algo, then it can also figure out that
there is another signature that it can process. 
The draft is silent about this scenario.

spt> See above.

In case c, the RPs is able to process both the weak and the strong
algorithms. If the RP decodes a SignerInfo with the "weak" algo, then it can
also figure out that there is another signature that it can process. What
about if a single bit from the digital signature made with the stronger
algorithm is changed by an attacker ? The digital signature is not
suppressed, but becomes invalid. 
What should the RP do ? The draft is silent about this scenario. 

spt> We will add text to address this - this part was going to go in to
section 5.

The draft does not say either whether it applies to the verification of a
CMS structure at the present time or at a time in the past. 

If it is the present time, both the "weak" and "strong" algorithms are safe,
and there is no concern for the "downgrade attack".

If it is a time in the past, then it is important to make a difference
between :

-	the weakness of hash algorithms, and 
-	the weakness of asymmetric algorithm of short keys. 

In the later case, time-stamping or time-marking over the digital signature
provides a protection. 

In the former case, time-stamping or time-marking over the digital signature
does not provide a protection, but an archive time-stamping provides a
protection, since a different and stronger hash algorithm may be used.

This means that there exist solutions to handle the problem without the need
to use the new signed attribute.

spt> I do not believe time should have anything to do with this. If you're
not worried about downgrade attacks then don't use the attribute.

In addition, RPs should know which hash algorithms is no more safe, which
means that they will not use the digital signature made with a weak
algorithm. They may try to use the newly defined MultipleSignatures signed
attribute to find out another signature made with a strong algorithm. In
other words, the "downgrade attack" 
is not a concern, but the newly defined MultipleSignatures signed attribute
is useful to link signatures from the same signer. The abstract should be
changed. Hereafter is a proposal: 

spt> While this might be true there are times when an RP won't know and this
draft addresses those instances.

      CMS SignedData includes the SignerInfo structure to convey per-
      signer information. SignedData supports multiple signers and 
      multiple signature algorithms per-signer with multiple SignerInfo 
      structures. During periods of algorithm migration, a signer may 
      wish to attach more than one SignerInfo. However, there is no 
      way to identify that they are from the same signer. This document 
      defines a signed attribute, its generation rules, and its 
      processing rules to allow a RP to detect SignerInfo structures 
      generated by the same signer.

spt> The point of the draft is to protect against a downgrade attack and I
will not change the abstract because I believe your suggestion misses the
point of the draft.

The processing rules for the various RPs should be given (six cases should
be covered).

spt> Agreed that we need to fill in the processing rules.

The MultipleSignature attribute, as defined, is not good enough, to
establish a link without ambiguity.

           MultipleSignature ::= SEQUENCE { 
             bodyHashAlg     DigestAlgorithIdentifier, 
             signAlg         SignatureAlgorithmIdentifier, 
             signAttrsHash   SignAttrsHash, 
             cert            ESSCertIDv2 OPTIONAL} 

If the same algorithm are used (e.g. SHA-1 with RSA) bodyHashAlg and signAlg
will likely be the same. 
If a signature has few signed attributes signAttrsHash will also likely be
the same. The difference will always be guaranteed with cert, which thus
should be made mandatory. 

spt> No the digest alg is sha-1 and the signature alg is rsa with sha-1 so
the values are different. 

Denis


>It is a companion document, not a replacement.
>
>Russ
>
>At 05:28 AM 12/20/2006, Denis Pinkas wrote:
>
>>How does this document relate to <draft-ietf-smime-cms-mult-sign-02.txt> ?
>>
>>Does it replace it ?
>>
>>Denis
>>
>> >A New Internet-Draft is available from the on-line Internet-Drafts 
>> >directories.
>> >This draft is a work item of the S/MIME Mail Security Working
>> Group of the IETF.
>> >
>> >       Title           : Multiple Signatures in S/MIME
>> >       Author(s)       : S. Turner
>> >       Filename        : draft-ietf-smime-multisig-00.txt
>> >       Pages           :
>> >       Date            : 2006-12-19
>> >
>> >         CMS SignedData includes the SignerInfo structure to convey per-
>> >         signer information. SignedData supports multiple signers and
>> >         multiple signature algorithms per-signer with multiple
SignerInfo
>> >         structures. If a signer attaches more than one
>> SignerInfo, there are
>> >         concerns that an attacker could perform a downgrade attack by
>> >         removing the SignerInfo(s) with the 'stronger' algorithm(s).
This
>> >         document defines a signed attribute, its generation rules, and
its
>> >         processing rules to allow signers to convey multiple SignerInfo
>> >         while protecting against downgrade attacks. Additionally, this
>> >         attribute may assist during periods of algorithm migration.
>> >
>> >
>> >A URL for this Internet-Draft is:
>> >http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-00.txt
>> >
>> >To remove yourself from the I-D Announcement list, send a message to 
>> >[e-mail] with the word unsubscribe in the body 
>> >of the message.
>> >You can also visit 
>> >https://www1.ietf.org/mailman/listinfo/I-D-announce
>> >to change your subscription settings.
>> >
>> >Internet-Drafts are also available by anonymous FTP. Login with the 
>> >username "anonymous" and a password of your e-mail address. After 
>> >logging in, type "cd internet-drafts" and then "get 
>> >draft-ietf-smime-multisig-00.txt".
>> >
>> >A list of Internet-Drafts directories can be found in 
>> >http://www.ietf.org/shadow.html or 
>> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >
>> >Internet-Drafts can also be obtained by e-mail.
>> >
>> >Send a message to:
>> >       [e-mail].
>> >In the body type:
>> >       "FILE /internet-drafts/draft-ietf-smime-multisig-00.txt".
>> >
>> >NOTE:  The mail server at ietf.org can return the document in
>> >       MIME-encoded form by using the "mpack" utility.  To use this
>> >       feature, insert the command "ENCODING mime" before the "FILE"
>> >       command.  To decode the response(s), you will need "munpack" or
>> >       a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>> >       exhibit different behavior, especially when dealing with
>> >       "multipart" MIME messages (i.e. documents which have been split
>> >       up into multiple messages), so check your local documentation on
>> >       how to manipulate these messages.
>> >
>> >Below is the data which will enable a MIME compliant mail reader 
>> >implementation to automatically retrieve the ASCII version of the 
>> >Internet-Draft.
>> >
>> >Content-Type: text/plain
>> >Content-ID:    <[e-mail]>
>> >
>> >ENCODING mime
>> >FILE /internet-drafts/draft-ietf-smime-multisig-00.txt