Re: SACRED Protocol (long!)

["Marshall T. Rose" <mrose+mtr.netnews@xxxxxxxxxxxxxxxx>]

> I certainly agree with you that we need to be thoughtful on security
> issues - and that's why we are specifying the use of a security
> framework (SASL, so far) and strong mechanisms within that framework
> (SRP, so far). There are no differencies between us there, AFAICT.
>
> SACRED in the form proposed this week by me is quite self-sufficient
> and puts very few requirements on the protocol it runs on top of.
> Compare once again with OCSP. The authors of OCSP wanted it to be
> possible to run OCSP over a variety of protocols, including http,
> smtp, and ldap. By making sure that OCSP could protect its own
> exchanges and minimizing the requirements on underlying protocols they
> achieved this. There are other examples of this, as I mentioned in my
> previous posting.

we just aren't communicating here...

the basic problem is this: if you write a protocol that both:

- maps onto multiple underlying protocols, and
- protects its own exchanges

then you are reinventing the wheel, spending more
design/implementation/review time on administrative overhead and less on the
application domain that you're trying to deal with.

in other words, you've managed to maximize the pain and focus all the
engineering energy on the non-essential parts of the system. probably not a
good trade-off.


> The fact is, BEEP is not universally implemented. We should allow for
> other bindings too, and make the work to do those mappings as simple
> as possible.

it's true that beep isn't universally implemented.

it's also true that do the other bindings, you'll have to complicate sacred
in order to make up for the fact that all these other mappings are on top of
transports that don't adequately deal with security, asynchrony, etc., etc.

and all for the benefit of fragmenting the marketplace, reducing the amount
of interoperability between implementations, promoting vendor lock-in, etc,
etc.

just because you can do it this way, doesn't mean you should.

/mtr