Re: [wss] Issue 84 - Resolved

[merlin <merlin@baltimore.ie>]

r/hlockhar@bea.com/2003.07.30/11:24:42
>
>> Can you explain why we are singling out the decryption
>> transform for prohibition? What about other transforms;
>> the basic XPath transform, the foo-bar transform, the
>> decryption transform Mark II, schema-centric c14n, ...?
>
>Yes, Issue 84 is about how the order of operations is specified and
>determined in WSS, in the cases where order matters. The Decryption
>Transform was proposed as a part of this solution. The issue is not
>transforms in general. Note that the X-C14N transform is required
>(effectively) and the STR Dereference Transform is endorsed in situations
>where it applies. If you believe there are other transforms that should be a
>part of WSS please raise a new issue on this subject.

You have proposed that we prohibit the decryption transform. I
see that as achieving nothing: I can define a decryption
transform mark II (which addresses my concern with &dcrpt;)
which is not prohibited.

The only useful things we can do are to say _nothing_ about
the decryption transform, or to provide a list of recommended
algorithms. Prohibiting one algorithm will achieve nothing.

On the subject of recommended algorithms, I'm not even
sure that our emphasis on exclusive canonicalization is
justified. Exclusive c14n is good for signatures within
data that will be relocated. While this makes sense for
signatures within the payload of a SOAP message, it is
irrelevant to signatures in SOAP headers over the SOAP body
or other SOAP headers. SOAP headers and bodys will not be
relocated into other contexts. Instead, our reliance on
exclusive c14n unnecessarily introduces the whole issue of
non visibly-utilized namespaces.

>> It would seem far more productive to come up with a
>> RECOMMENDED set of algorithms - transforms, c14n,
>> digest, signature, encryption, that SHOULD be supported
>> and SHOULD be used, and say nothing about anything else.
>>
>> If people choose to use other algorithms then they know
>> that they cannot guarantee interop with wss-compliant
>> software. Prohibiting just one thing doesn't seem, to me,
>> to achieve anything.
>>
>> For example, by not prohibiting RC2 and RSA/OAEP/MGF1/MD5
>> with non-standard parameters, are you implying that all
>> implementations must support them?
>
>It is a widely agreed principle that security mechanisms should be as simple
>as they can be and still meet the requirements. More complex mechanisms are
>harder to analyze, more likely to have non-obvious properties and more
>likely to be incorrectly implemented. Historically far more security flaws
>have been found in complex schemes than simple ones and the relationship is
>clearly greater than linear.
>
>It has been my goal all along to eliminate features which have identified
>use, have fuzzy semantics or simply provide an alternative way of doing
>exactly the same thing. I am all for providing the maximum flexibility to
>implementers, but they will expect us to produce security implementations
>which interoperate and actually have the advertised security properties.
>Note that even SOAP limits flexibility in various ways, notably in the rules
>for processing headers.
>
>In the case of the DT, as I noted, it can still be used in payloads or
>attachments. However, it seems to be unnecessary and not useful in defining
>the order of operations in WSS. If we leave it in, processing will be more
>complex, implementations that much larger and the chances of unexpected
>"gotcha's" greater.
>
>Of couse I freely concede this is all based on my assertion that there is no
>sensible usecase which justifies the additional complexity. A single
>compelling usecase could completely alter my position. But just saying
>"somebody might use if for something, sometime" doesn't do it for me.

I don't believe that adding text that prohibits _one_ algorithm
does anything to solve the complexity problem; there are an
unbounded number of complex, non-prohibited algorithms out
there. If the transform doesn't add anything to our processing
model, we should simply not bring it into the discussion.

>> There is an important distinction between use of the
>> decryption transform and insertion of an enc:ReferenceList
>> or enc:EncryptedKey in a WSS header. The enc:* elements in
>> a security header destructively decrypt the referenced
>> encrypted data, resulting in an unencrypted payload. The
>> decryption transform, on the other hand, performs
>> non-destructive decryption, solely for the purpose of
>> verification.
>
>Well this may be the intent, but the current core spec by no means makes
>this clear. In any event, it does not affect my argument about the
>possession of secrets. I see no value to having two distinct nodes
>possessing the same secret key that perform the same decryption operation
>twice.
>
>However, perhaps someone else can suggest a case where this is useful.

If the spec is not clear, it needs to be. What are the
semantics of an intermediary receiving an enc:ReferenceList
or enc:EncryptedKey header? Operate destructively or non-
destructively?

The two nodes do not possess the same secret key; the
transient secret key is transported under each intended
recipient's public key. So, my SOAP gateway can inspect,
archive and validate messages that I send out, and you
can validate and process them when they arrive.

>[...]
>
>> Also worth noting is that if
>> Bob does not get the decryption transform, then there
>> may be subtle differences between what he and Eve verify,
>> depending on the interaction of the &c14n; embedded in
>> &dcrpt; and the recommended use of &exc-c14n; in wss.
>>
>> [ Aside: Yes, I think this is a flaw in the specification
>> of &dcrpt;. In retrospect, I think it should have been
>> specified as &deref; is specified, with a C14nMethod
>> parameter. ]
>>
>> Obviously Eve could make a copy of the document before
>> verification, then strip her header from the original before
>> passing it on; or, if she shares a secret with Bob, she
>> could re-encrypt parts of the document. However, all such
>> approaches have a non-trivial impact on intermediaries.
>
>These comments further convince me that this is a can of worms we are wise
>not to open.

It's a can of worms that we've already opened, to some
extent, by using exclusive c14n: The decryption transform
uses c14n, which is 'safe'. It is the other case - with
exclusive c14n - where you have to be much more careful
about verifying what was actually signed.

merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com