OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dss-comment] DSS as a encryption/decryption oracle.


I agree this could be appropriate regarding implementation guidance.  I
suggest that DSS-X consider this as input to the maintenance process.


> -----Original Message-----
> From: Timothy J. Miller [mailto:tmiller@mitre.org]
> Sent: 03 July 2007 20:01
> To: Pope, Nick
> Cc: dss-comment@lists.oasis-open.org
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]