More on SASL.
Carl-Uno
-----Original Message-----
From: Ned Freed [mailto:Ned.Freed at innosoft.com]
Sent: Friday, November 13, 1998 10:10 AM
To: IETF Transport Layer Security WG
Cc: IETF Transport Layer Security WG; IETF Transport Layer Security WG
Subject: Re: Last Call: Addition of Kerberos Cipher Suites to Transport
Layer Security (TLS) to Proposed Standard
I found it easy to ignore the rest of your rather nasty tirade. The
following,
however, requires a response:
> Second of all, SASL is objectionable, and the security community has been
> silent in this regard for far too long. I assume that SASL actually made
> it to RFC only because it was not associated with a working group (much
> less a security working group) and has not been subject to appropriate
> scutiny. SASL specifies next to nothing and specification of SASL
> mechanisms is ad hoc. I fail to see how SASL is "superior" in any way -
> perhaps people from the security community could shed some light on this?.
Not only is this entirely incorrect, much of it is precisely backwards.
First of all, specifications developed outside working groups routinely
receive
far more scrutiny than those developed inside working groups. There are
implicit process steps that insure this (four week last call rather than
two)
as well as implicit ones well understood by people who review such
documents.
I'm one of the people who routinely reviews application layer documents,
including those relating to application layer security, and I can assure you
that the first thing I look at is whether or not the document went through
the
working group process. And if it did not I get out a much larger collection
of
editing pencils than I would for working group product. Simply put, my
approach
is that working group product gets the benefit of the doubt, whereas private
contributions do not.
Now, I'm by no means sure that all working group product merits such
consideration, especially lately, where we've had cases of fairly egregious
outstanding issues surviving working group last call. But the jury is
still out on that.
Now, I'm only a former apps area directorate member and current IAB member,
not
a security AD or a member of the security directorate. But I cannot imagine
that the policies of the security directorate differs substantially from
those used elsewhere. It would not make sense for them to do so.
Second, you say that SASL specifieds "next to nothing". This is partly true
--
SASL specifies a simple framework and some initial mechanisms and leaves the
door open to the development of additional mechanisms.
But the specification of a small set of mechanisms is considered by most to
be
a feature of SASL, not a bug. Complex frameworks and lots of base mechanisms
may be justifiable in some contexts, but not in the context of a facility
primarily oriented towards simple application layer authentication. And
less
really is more, especially in security, where unnecessary complexity makes
analysis harder and holes more likely.
And in the final analysis, the proof is in the pudding -- the uptake of SASL
support in many applications has been one of the most dramatic lessons in
protocol deployment I've ever seen.
In summary, I see finding fault with a specification because of its origin
as
nothing more than a case of NIH syndrome. And confusing complexity with
quality
is entirely wrong. If anything, it is the other way around.
Ned
---
You are currently subscribed to ietf-tls as: [cmanros at cp10.es.xerox.coM]
To unsubscribe, forward this message to
leave-ietf-tls-641F at lists.consensus.com