Re: [dss] Namespace inheritance, other approach

[Trevor Perrin <trevp@trevp.net>]

Konrad,

Inline again -

Konrad Lanz wrote:
> 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.
[...]
> 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.

It's unclear to me who's the attacker and who's the victim - the last 
paragraph says "maliciously modified client", but it also says "if the 
client by mistake loses original namespace context".

If the client is only tricking himself, I don't see a problem :-)


> [...] 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.

I agree that a buggy client could make this mistake, and could end up 
suffering for it (whether in interop problems, or even some weird 
security problem).

I also agree that servers should detect and warn clients that make this 
mistake.

However, I believe (and I'm hoping) that this mistake only affects the 
client who makes it, and doesn't create an opportunity for attacking the 
server or anyone else.


> 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.

I'd like to understand your last paragraph:
  - Does valid redeclaration of namespaces require exclusive 
canonicalization on the clientside?  Isn't it enough for the client to 
just redeclare the namespaces, and leave the rest of canonicalization to 
the server?  That seems less of a burden than full canonicalization, and 
potentially less of a burden than opaque encoding.
  - Are you thinking the client would need to add exclusive 
canonicalization to the list of ds:Transforms, and this would appear in 
the output signature?  I think that's unnecessary.  XML-DSIG requires 
that XML data is canonicalized before being signed.  By redeclaring 
namespaces, the client is just giving the server the data needed to 
apply this canonicalization, not adding anything new to the signature.


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

Agreed.

> 
> 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.

Do you mean redeclaring namespace (like II-V) is a lot clearer, or 
opaque encoding?


Trevor