RE: Protocol: control specifications.

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Ron, you'll find an answer to your last message on the bottom.
Mark, thanks for your X.500 example.

I'll keep replying while the argument is going, but if we still disagree
after this message, and no X.500 (or LDAP?) servers we should allow for
turn up which do check criticality, I'll accept the case for disallowing
the criticality check as lost.

I still want language which explicitly allows control specs to mandate
criticality, or maybe just to mandate TRUE criticality, but I think
that's another subthread.

Kurt D. Zeilenga writes:
>At 06:02 PM 3/9/2004, Hallvard B Furuseth wrote:

>>I do wish someone knew what some X.500 servers do about wrong
>>criticality.
> 
> I am pretty sure they behave in a manner consistent with most
> LDAP servers.  (...)
> 
> But then, again, I don't think it matters all that much.

Well, an LDAP gateway to an X.500 server which checked criticality would
be breaking the [Protocol] spec, unless each relevant control spec said
(against [Protocol]'s recommendation) that the server may return an
error for wrong criticality.  I agree there could be stronger arguments
against.  Anyway, the only X.500 example that have been posted so far
goes against me:-)

> We
> should be more concerned by what LDAP implementatoins are doing,
> and how to revise the LDAP specification such that new
> implementations are able to interoperate with existing as
> well as other new implementations (...)

A check would only break broken clients, so I'm not too concerned.

>>And I don't see why servers should be forbidden to catch this particular
>>client error.
> 
> They aren't forbidden per say, but prohibited from checking unless the
> control specification states a specific requirement (against the guidance
> against overloading criticality) for that they implement such a check.

Right, but I'm not talking about individual control specs that alter the
semantics to the criticality field.

I'm talking about control specs that simply mandate a criticality, and
servers that check mandated criticalities in general.
That and invalid values in search filters are the only errors I can
think of at the moment which servers will be forbidden to catch.

> Because that can lead to interoperability problems.  That is, while
> you intend this to catch errors during development, it might have the
> effect of producing non-conforming clients (because they follow a
> server which doesn't provide the diagnostic, or provide s a bogus
> diagnostic).

That's the weirdest argument for anything I've heard for a long time.
Server bugs can happen in any area no matter what we specify.  Clients
that cater to such errors should take care to work with correct servers
as well.  If we follow your argument, LDAP should have had fewer and
less informative error codes, and no diagnosticMessage.  And e.g.
require clients to handle spaces after commas in DNs, in case some
server returns that.  That would be more interesting, since I still see
DNs with spaces.  I'm not even sure if that's a bug or not.

> It also will lead to cases where an otherwise conforming client and
> otherwise conforming server fail to interoperate simply because the
> fail to agree to the proper value of criticality.  Such disagreements
> should not be fatal to interoperability.

The same could be said of any bug or optional feature.  Spaces after
commas in DNs, integers prefixed with zeroes, not sending Bind after
StartTLS (even though other servers may invalidate the association).

(BTW, I assume either your client or server above would be conforming,
not just 'otherwise conforming'.  There are only two choices for
criticality, after all.)

> Also, having the server verify criticality limits the kinds of extensions
> which can be made to LDAP.  That is, it makes it harder to extend
> controls to support new operations, makes it harder to extend operations
> extended by controls with new controls, etc..

You mean it makes the criticality check harder to implement?  I don't
see that.  The criticality of most controls can be verified when the
control is parsed.  The exception is if the control spec - or the spec
of another extension which overrides the control spec - says that the
control is critical in circumstances which can not be determined just by
parsing that control.

Anyway, so what?  It's the implementor's choice how much error checking
to do.  Thorough error checking has always been tedious.


> In the same vein, consider issues regarding changes to the set of
> appropriate messages which a control can be attached to.

Now that you mention it, I note that a literal reading of rfc2251
forbids the server to return protocolError for the wrong criticality of
an inappropriate control.  (It must return unsupportedCriticalExtension
if it is marked critical, and ignore it otherwise.)  However, the same
goes for a control with malformed controlValue (inside a well-formed
OCTET STRING, that is), and I don't expect implementations take care to
ignore parse errors in inappropriate controls.

Except for that, this has nothing to do with criticality, but:

> Should a
> server verify that a control whose specification said "MUST be
> attached only to a search request" treat attachment of the control to
> a non-search request as a protocol error?

According to [Protocol] and rfc2251, attaching an inappropriate control
to an operation is not an error, it just means the control should not be
applied.  But if the control is marked critical as well, the server
returns an error.  (unsupportedCriticalExtension, not protocolError.)

I guess one could claim that your example doesn't actually state that
the control is only appropriate for Search, and therefore that the
server MAY return protocolError if it is attached to other operations.

> Shouldn't it be allowed for
> a new extended operation to say that this old control can not be
> attached to the new operation?

Sure.  So when a server which already implements the control, also
implements the new operation, it adds the new operation to the list
of operations appropriate for the control.  What of it?

> What if the appropriate criticality for this new operation was
> different?  Would it be appropriate to new extended operation to say
> "old control MUST be critical" even though the specification for that
> old control said it MUST always be non-critical?

I don't know.  I wouldn't write such an extension without asking
e.g. ldapext for advice.  But that's still another issue than verifying
criticality.  It is an example of making the criticality more cumbersome
to verify as discussed above, but in that regard it is no different from
if the control spec itself said that it is critical with one operation
and non-critical with another.

> And what happens when a new security consideration arises that suggests
> that a control, whose previous specification said be non-critical, should
> not be critical in a some cases.  A sender verification requirement would
> disallow simply changing the guidance provided to the client developer
> (or user), but force the introduction of a replacement control.
>
> That is, have criticality be "in the eye of the client" allows a great
> deal of revision and extension flexibility.

Addressed in my recent message 'Mandated non-critical controls'.

>> There are plenty of client errors that servers may, but need not,
>> catch.  I think it's an important client error to catch, since it can
>> be so damaging.
> 
> It can be damaging to unnecessarily catch errors that don't matter.
> That is, the "be liberal in what you accept" principle is quite sound.

True, but as you may have noticed, my point is that this error does
matter.  If we are going to be liberal in _everything_ we accept, please
remove error returns from [Strprep] and [SASLPrep].  BTW, that's
something I want anyway, so I guess we both are on both sides of the
fence with regards to that principle.

>> As important as rejecting cleartext password binds done without TLS.
> 
> Bad example.  Use of cleartext passwords without TLS is not a protocol
> error.

I didn't mean to imply it was.  It is example of what Ron called
  "I didn't do it. I could have but, na-na-na, you got the (***)
  wrong. Let that teach you a lesson!"
which, as it happens, this example was a reply to.  And I think
both are for good reasons.

If you want an example of rejecting an error which one is able to handle
just because some other server might reject it (as Ron complained this
was not an example of), try a server which is stricter with the syntax
of attributes in update requests than with filter items, and refuses to
add an integer value with leading zeroes instead of stripping the
leading zeroes as it does in filters.  Or maybe rejecting DNs with
spaces, it's not clear to me if those are errors or not.

>> After all, rejecting the bind doesn't protect the password, that has
>> already been sent in the clear.  But it encourages the client to be
>> fixed.
> 
> Some argue that such checks encourage complaints to be made to the
> server developer not the client developer.  Some vendors don't think
> its there place to police other vendors.

Vendors who think so are free to act accordingly.

Vendors can also implement optional checking in order to satisfy people
on both sides of that argument.  Except in the case of checking control
criticality.

For some types of applications, I really appreciate programs with an
option for really paranoid error checking, which I only turn on for bug
hunts and for development of other software.

-- 
Hallvard