Carl-Uno
-----Original Message-----
From: Ned Freed [mailto:Ned.Freed@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@cp10.es.xerox.coM] To unsubscribe, forward this message to leave-ietf-tls-641F@lists.consensus.com