Re: [dss] Namespace inheritance, other approach

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Hi Trevor,

please see below for a namespace (implementation) attack using a 
malicious client and reusing namespaces of the transport protocol and 
how to prevent that.

Trevor Perrin wrote:
> Konrad Lanz wrote: 
> [...]
>> I'd say that a server should be very wary when signing data that uses 
>> prefixes defined by DSS and
>> not having redeclared them inside the payload which is to be signed. 
>> I can imagine that this is very
>> susceptible to attacks.
>
> Could you describe the attack?

To be precise it is rather an attack on an incorrect implementation than
on the protocol per se.

> I understand that a client that doesn't redeclare prefixes inside the 
> payload might receive a signature on something he didn't intend.

That is the point, and I would like to illustrate this further with an 
example and a few reasonable assumptions.

Assuming someone uses the the dss prefix for a namespace like the
following
xmlns:dss="http://www.some-blacklist.com/disabled/server/signatures"; and 
someone else uses a dss:KeySelector from the 
xmlns:dss="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd";
namespace in a Signature.

Now assume some system using signed dss:KeysSelectors from
xmlns:dss="...disabled/server/signatures" that are excluded from trust, 
but signed dss:KeysSelectors from xmlns:dss="...oasis...." are
trusted.

Then

<dss:XMLData>
  <dss:KeySelector
xmlns:dss="http://www.some-blacklist.com/disallowed/server/signer/Keys";>
  [...]
  </dss:KeySelector>
</dss:XMLData>

is a lot different from

<dss:XMLData>
  <dss:KeySelector>
  [...]
  </dss:KeySelector>
</dss:XMLData>

Essentially someone can use a malicious modified client to request a
signature over a dss:KeySelector in a not redeclared namespace, thus 
essentially retrieving a signature over a dss:KeySelector in the
namespace xmlns:dss="...oasis...." if the client by mistake losses 
original namespace context of the data.

Then one can expect that exclusive canonicalization on the server side 
will do the job of adding xmlns:dss="...oasis....".

> However, since the server canonicalizes before signing, the server 
> will always know what it is signing. 

One can argue that if you send the data without namespace redeclaration 
this is exactly what is intended and it should be interpreted as being 
in the outer namespace of the transport protocol in scope so the server 
only signs what it gets.

Nevertheless this is not in an analogy to what would happen if the 
content was base64 encoded or if the signature was not created by dss. 
In the latter usually the complete DOM data structure also holding the 
xmlns:dss="...disabled/server/signatures" would still be available and 
not lost.

However I think it is quite likely that this loss of information can 
happen in an implementation and hence opening an opportunity for an
adversary.

To prevent this loss it can be detected easily by the server and will
be prevented by a requirement for XMLData to be free of any ancestry 
context.

> So this is simply a broken 
> client getting broken results [...]

That's the point and a suspicious (broken) client would get a 
questionable unanticipated (maybe ambiguous) result.

I hope this makes sense.

best regards

Konrad


P.S.: Consider the following examples and note that transmitting

(I):
<dss:XMLData>
  <dss:KeySelector>
  [...]
  </dss:KeySelector>
</dss:XMLData>

is equal to transmitting

(II):
<dss:XMLData>
  <dss:KeySelector 
xmlns:dss="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd";>
  [...]
  </dss:KeySelector>
</dss:XMLData>

which also is equal to

(III):
<XMLData 
xmlns="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd";
xmlns:dss="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd";>
  <dss:KeySelector>
  [...]
  </dss:KeySelector>
</XMLData>

(I - III) require exclusive canonicalization of <dss:KeySelector> to 
produce equal digest inputs.

But (I - III) are not the same as

(IV):
<dss:XMLData>
  <dss:KeySelector 
xmlns:dss="http://www.some-blacklist.com/disallowed/server/signer/Keys";>
  [...]
  </dss:KeySelector>
</dss:XMLData>

which in turn is however the same as transmitting

(V):
<XMLData 
xmlns="http://docs.oasis-open.org/dss/oasis-dss-1.0-core-schema-cd-02.xsd";
xmlns:dss="http://www.some-blacklist.com/disallowed/server/signer/Keys";>
  <dss:KeySelector>
  [...]
  </dss:KeySelector>
</XMLData>

Valid redeclaration of namespaces (II,IV) could be achieved by exclusive 
canonicalization on the clientside which would have to be added at the 
end of the ds:Transforms already applied by the client to ensure that
xmlns:dss="..." is always there.
This however would impose a considerable burden on the client.

Hence I would advocate for disallowing (I) and so forcing the client to
consciously use namespaces in a clear way.

Summarizing all this is guaranteed by ancestry context free XMLData and 
the tools will throw an exception if a prefix appears that has not been 
declared inside the payload or at least inside XMLData.
I think it is also a lot clearer. Please see (II-V) for valid requests.