Subject: can i get some help with the unwashed?

From: Marshall Rose <[email-masked]>
Date: Wed, 18 Dec 2002 11:57:04 -0800

hi. can some folks from this list pop over to [email-masked] and
explain to some of the highly-opinionated new arrivals why sasl is a
good thing? my gut reaction is to write the guy off as a
mini-me-for-djb, but perhaps i should be more kind in my old age.

specifically, the ietf chartered a syslog wg some time ago. the wg
developed two specs for doing syslog, one is "reliable syslog", which is
beep-based where you pick the bells-and-whistles you want, and the other
is "signed syslog", which is udp-based with some clever crypto to
provide in-order delivery over a certain timeframe.

the folks at sdsc produced an implementation of reliable syslog and
announced it on the [email-masked] list, where some folks
hit the roof because what got standardized doesn't match their model.

as expected, the arguments boil down to: just run tcp/ssl and it's all good.

so i try to start the education process by asking why sasl got put into the
ietf's apps if we already had tls.

the response i got back is such a discontinuity from the real world that i'm
tempted to just ignore it.  however, some folks on this list might feel a need
to bring light to the masses, so  i'm forwarding this note here.

/mtr

ps: obviously, i see the "we hate beep" stuff from time-to-time, and
frankly, i don't really care. if someone sits down and does the work,
they'll figure out why. however, since the message is specifically
about sasl, i thought i'd bring it up here...

"enjoy!"
    
/mtr

Subject: Re: Any chance for a Simple Reliable Syslog Protocol?
From: Bennett Todd <[email-masked]>
To: Marshall Rose <[email-masked]>
Cc: [email-masked]
Date: Wed, 18 Dec 2002 09:08:52 -0500

2002-12-17-18:11:43 Marshall Rose:
> here's an interesting thought experiment: if TLS (nee SSL) is
> around, why did the IETF add SASL to all of its application
> protocols?

Errh, because the Cyrus team implemented it, and nobody was
offering a better way to stuff authentication into SMTP? The
hideous overcomplexity of SASL has been the main barrier to getting
authenticated SMTP more widely deployed. Notably, the Cyrus SASL
libraries --- the only SASL implementation available[1] --- have
been found to have security bugs in them.

> to understand the answer to this, is to understand why TLS, while
> very good at what it does, doesn't meet the requirements of many
> environments.

To understand why SMTP auth is so rarely deployed, and why so many
people are using the revolting pop-before-smtp kluge instead, is to
understand why wading off into the bright open and inventing your
own crypto protocols from scratch is best avoided.

> here are two hints: kerberized enterprises?

Haven't ever cared especially; even when I've worked in a totally
kerberized enterprise, certs were just as good for host-to-host
auth (and operationally equivalent). But now that I do a quick RFC
search, it looks like RFC 2712 describes Kerberos authentication for
TLS, so it looks like someone decided to enable the general-purpose
tool to encompass that problem.

> integrity-sans-privacy?

I'm having trouble envisioning a real motivation for that, but it
seems to be supported within TLS as it stands, BulkCipherAlgorithm
null.

> again, it's not that TLS isn't adequate, it's perfectly adequate
> and extensible for its mission. the problem is that its mission
> may not have quite the reach that a lot of folks require...

Before concluding that, it's good to make positively certain TLS
can't do the job as it stands, and that it's impractical to extend
it, before going out and re-inventing the functionality; there's a
lot of engineering benefit to re-using existing analysis and
implementation, and if the existing protocol is inadequate for a new
job, better to extend it, and thereby leave it fitted to a broader
set of tasks, then re-implementing the functionality elsewhere.

I really think the security needs of syslog are best met by just
getting it off UDP and onto TCP, whereupon it's easy to transport it
securely.

-Bennett

[1] I've heard of other SASL library implementation attempts. I
    haven't heard of any that got far enough to be a viable
    alternative to Cyrus SASL for a real application.