[wss] ISSUE: denial of service attacks

Version 11 [line 1478]

These can be grouped into two classes of errors: unsupported
and failure. For the case of 
unsupported errors, the recipient MAY provide a response that informs
the sender of supported 
formats, etc. For failure errors, the recipient MAY choose not to
respond, as this may be a form 
of Denial of Service (DOS) or cryptographic attack. We combine
signature and encryption
failures to mitigate certain types of attacks

If a failure is returned to a sender then the failure MUST be
reported using SOAP's Fault
mechanism. The following tables outline the predefined security fault
codes. The "unsupported"
class of errors are: 
First, the argument against a must for failure errors doesn't apply
to the "unsupported errors", so I think the first MAY should be
changed to be a MUST

With regards to denial of service attacks, I mentioned the above on an
email list that was discussing whether specific responses should be
required to certain ill-formed messages and the general consensus of (the
non security experts) there was that they should require responses within
their protocol, and that anything that was done to defeat a denial of
service attack would be outside the scope of their spec.  I agreed
with them and I think the same argument applies to WSS. 

With regards to crypto attacks I can be corrected by the crypto experts,
but I think crypo attacks can be dealt with by providing a generic
wsse:InvalidSecurity response that provides no more information than does
a failure to respond.

So I propose that the above paragraphs be replaced by something like

If a service does not perform its normal operation because of the
contents of the Security header, then that MUST be reported using SOAP's
Fault Mechanism.  However, this specification does not preclude
action being taken by a site to suppress processing of messages that
appear to be part of a denial of service or cryptographic
attack.