RE: Comments on Encrypted Header Proposal

["Hal Lockhart" <hlockhar@bea.com>]

Ok, I stand corrected. Gudge pointed out that section 2.6 pretty clearly says there is an atomic model for understanding of headers. This seems foolish to me, since there is no required atomic model for errors when processing headers, however we must abide by the spec.

Strictly speaking, there is no way to follow this rule, or at least no current implementation does. Since, even under this proposal, the security header must be processed before you can see that an encrypted mandatory header that you do not understgand is present. It that point you have to roll back any persistent effects of processing the security header. (Storing a Token or key is the only one that comes to mind.)

It seems much more reasonable to me to simply process the security headers targeted to this node and then perform the processing SOAP requires. Because of possible overlaps, the security header must be processed in order, regardless of mustUnderstand setting, so I still do not see the purpose of the encrypted header.

Surely the intent can't be to say that since the "real" header has been replaced with <EncryptedHeader> and since we understand <EncryptedHeader> we are all set. This honors the letter of SOAP, but not the spirit. Why it seems to me it would be equally good to just use <EncryptedData>, which since it lacks a mustUnderstand attribute, defaults to false, and declare our obligation to SOAP discharged.

I am still waiting to see someone present the processing model that is enabled (not merely optimized) by the proposal.

Hal 

> -----Original Message-----
> From: Hal Lockhart 
> Sent: Sunday, October 31, 2004 8:45 PM
> To: wss@lists.oasis-open.org
> Cc: Corinna Witt (E-mail)
> Subject: Comments on Encrypted Header Proposal
> 
> 
> Thoughts and discussions arising from the Encrypted Header 
> proposal have touched on many aspects of Web Services, 
> including the implications of diverse specifications for each 
> other, the design of distributed systems infrastructure, the 
> goals of schema checking and the composing of distinct 
> services. I will confine my comments narrowly to the proposal 
> at this time. However my response has been delayed longer 
> than it should have been. I apologize for any inconvenience 
> that this causes.
> 
> Part of the proposal reads:
> "The SOAP processing model requires that a SOAP processor 
> MUST examine all mandatory headers targeted at the role of 
> the processor and determine that they can be understood 
> before it can commence processing any of the headers"
> 
> What SOAP 1.1 actually says is:
> 
> "If a header element is tagged with a SOAP mustUnderstand 
> attribute with a value of "1", the recipient of that header 
> entry either MUST obey the semantics (as conveyed by the 
> fully qualified name of the element) and process correctly to 
> those semantics, or MUST fail processing the message (see 
> section 4.4)."
> 
> SOAP 1.2 says:
> "Therefore, for every mandatory SOAP header block targeted to 
> a node, that node MUST either process the header block or not 
> process the SOAP message at all, and instead generate a fault 
> (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault)."
> 
> As far as I can see, an implementation which simply processed 
> each header in some order and if it found one that could not 
> process, generated a fault, ceased processing the message and 
> did not pass the message to the application would comply with 
> both of these. I do not interpret either of them as saying 
> that all intermediate results must be rolled back to the 
> point before the message was received. I feel confident that 
> the mustUnderstand feature was not intended to mandate some 
> kind of atomic, all or nothing behavior on the part of 
> infrastructure services. I know its purpose is to facilitate 
> future evolution primarily in the normal case when the 
> default value of "False" is in force.
> 
> It seems clear at least that the relationship between the 
> application and infrastructure services should not be atomic. 
> Aside from the cost of implementation (paid over every 
> routine interaction) there are benefits in partitioning the 
> error models. For example, in TCP a message that generates an 
> HTTP error can still update a window counter kept at a lower 
> layer. To pick a WSS example, a message that failed 
> processing might bear a Token that was referenced in a future 
> message, eliminating the need to retransmit it.
> 
> Therefore as far as I can see, the desire to scan the headers 
> for the mustUnderstand attribute is at best an optimization. 
> But is a standard rule of thumb that you don't optimize error 
> cases. The reason is simple. In a debugged, production system 
> (where performance matters) the ratio of errors to total 
> messages will be 3 or 4 orders of magnitude at least. There 
> is not much benefit even if a gain is found.
> 
> Further, I believe that the case of encrypted headers will 
> itself be rare. In fact, assuming that headers are generated 
> and consumed by infrastructure elements, such as routing, 
> reliability and security, I have not been able to think of a 
> plausible usecase for encryption of a header. I can see lots 
> of reasons for integrity protection, but few for 
> confidentiality. In most cases, an infrastructure header will 
> in effect be known plaintext, so encrypting it would be 
> positively undesirable.
> 
> Also notice that the only benefit will be in abandoning the 
> processing immediately when an unsupported mandatory header 
> is found. Once it is discovered that the message can be 
> processed, it is necessary to perform all the cryptographic 
> operations specified in the security header in the correct 
> sequence, because of the possibility of overlapping 
> signatures or encryptions.
> 
> The proposal in essence is to encrypt the entire header, wrap 
> it in a new element and decorate that with plaintext copies 
> of the actor(role) and mustUndertand attributes. But this 
> does not meet the stated requirement. As Corinna Witt (BEA) 
> pointed out to me, in order to decide if you can process a 
> header, mandatory or not, you must know the name of the 
> header (outermost) element. Under this proposal you must 
> decrypt the message anyway to find this out. Thus at the most 
> basic level the proposal does not meet its own requirement.
> 
> Perhaps this could be rectified also by echoing the name of 
> the header in the surrounding wrapper. However this raises 
> new questions. Suppose it is a requirement to keep the name 
> of the header secret? Since I have not been able to think of 
> any encryption uescases, I do not feel confident asserting 
> this will never be the case. Then this scheme will not be allowed.
> 
> Meanwhile we have to implement a complex scheme with many 
> unspecified details. Now we have two processing models, one 
> for body and one for headers. Actually since this scheme is 
> not mandatory, three models, since headers can be done two 
> ways. We also  have duplicated information (header name, 
> actor/role & mustUnderstand). What if the copies differ? Is 
> it an error or does one control?
> 
> This does not seem worth it to optimize a rare case.
> 
> Perhaps there is a case we should worry about. What if a SOAP 
> node fails to detect a header directed to its role and marked 
> mandatory, because it is decrypted by a role that operates 
> later on as by virtue of the order the message is routed. 
> This might cause it to violate the rules quoted above.
> 
> One view is that since SOAP explicitly says there is no way 
> to assure or determine the order a message will reach a node 
> supporting a given role (except for the ultimate recipient) 
> that this problem does not need to be addressed. Certainly 
> covering all the cases would be difficult, but perhaps we can 
> prevent a few common errors. 
> 
> For example, we could create a rule that the node supporting 
> the ultimate recipient role generate a fault if an 
> unprocessed security header is left in the message. It might 
> also be possible to add a rule saying that a sender must 
> never encrypt a header directed at a different role from the 
> security header controlling the encryption. Correspondingly 
> the receiver would be required to generate a fault if such a 
> case was detected in a received message. However, perhaps 
> some would view the latter rule (or even both of them) as 
> unduly restrictive to MEP choice.
> 
> It is entirely possible that I have failed to understand some 
> aspects of the proposal or properly interpret the 
> requirements. I hope that others will be able to clarify my 
> thinking. For me the most useful information would be for 
> someone to give an example of a receiver's processing model, 
> showing how the steps would be facilitated by new features.
> 
> I will add a final thought on schema checking. Different 
> alternative approaches are discussed in the proposal in terms 
> of whether or not the final (encrypted) form of the message 
> was schema valid. I think it is important to keep in mind the 
> purpose behind schema checking. It is to determine if the 
> thing you are processing is at least roughly the sort of 
> object you expect. I don't see the point of having every 
> schema point here and there and say there might be encrypted 
> data here, but not really checking if after decryption, you 
> got what you expected. There is no real benefit in terms of 
> catching errors early.
> 
> Some people believe the XML Encryption WG should have solved 
> the problem of encrypted data not being schema valid. Since 
> they did not, perhaps XML or Schema or SOAP should adopt the 
> formal or informal rule that encrypted data is a special case 
> and is valid anywhere. That would be no worse than current 
> solutions and would eliminate the need to do it individually 
> in each spec. In any case I do not think this is a problem 
> WSS is responsible for solving.
> 
> Hal
>