Tim,
I agree this could be appropriate regarding implementation guidance. I
suggest that DSS-X consider this as input to the maintenance process.
Nick
> -----Original Message-----
> From: Timothy J. Miller [mailto:]
> Sent: 03 July 2007 20:01
> To: Pope, Nick
> Cc:
> Subject: Re: [dss-comment] DSS as a encryption/decryption oracle.
>
> On Jul 3, 2007, at 11:48 AM, Pope, Nick wrote:
>
> > Are you talking here about an attack on use for DSS for encryption /
> > decryption or for signing?
>
> Signing.
>
> > If this relates to signatures then the signing will only be invoked by
> > authorised individuals and so will not be subject to external attack.
>
> Nothing stops an authorized person from attacking the service. Also,
> since the general implication is that DSS users generally lack strong
> authentication (otherwise they could sign it themselves), it is
> possible that an unauthorized user has gained access to an authorized
> user's credentials.
>
> The protocol itself needs protection against these kinds of attacks.
> See RFC3218, "Preventing the Million Message Attack on Cryptographic
> Message Syntax," for an example of what I mean.
>
> Here's what I think are necessary:
>
> - The service must implement signature schemes that are provably
> secure against both chosen-plaintext and chosen-ciphertext attacks.
>
> - The service must not allow unauthenticated signing operations. This
> impedes the ability of any attacker to use the service as an oracle.
>
> - The service must sign only objects, not hashes of objects. This
> impedes an insider's ability to utilize the service as an oracle.
>
> - The service must implement detection and prevention of misuse. This
> impedes the use of the service as an oracle, and provides support for
> denial-of-service protection. However, as the "normal" volume of the
> service increases, the ability to detect misuse decreases.
>
> - The service must utilize hardware security modules for private key
> operations. This supports service non-repudiation.
>
> - The service must implement some form of authority delegation. This
> provides support for attribution and non-repudiation.
>
> If nothing else this should be covered in implementation guidance, as
> security considerations, which appear to be missing from the standard.
>
> -- Tim
