Subject: RE: Compression under SASL was Re: Huffman coding?

From: Alan Lloyd <[email-masked]>
Date: Thu, 28 May 1998 09:00:25 +1000

Well said Chris - some of us have to build big systems and deal with
trust models in a distributed - authenticated environment - having sand
and rubber security components being promoted as the foundations is a
good way of making sure no one uses them.
Its easy to change a spec and a bit of code on the fly.. Try changing a
military, banking or telephone system in the same way.

regards alan

> -----Original Message-----
> From:	Chris Newman [SMTP:[email-masked]]
> Sent:	Wednesday, May 20, 1998 7:25 AM
> To:	Harald Alvestrand
> Cc:	[email-masked]
> Subject:	Re: Compression under SASL  was Re: Huffman coding?
> 
> On Mon, 18 May 1998, Harald Alvestrand wrote:
> > This reminds me of the "application layer framing" approach that
> I've
> > seen bandied about around MMUSIC/AVT. It's a good argument.
> > But in that case, we may need to turn SASL into Simple Anything
> Session Layer,
> > with slots for authentication, encryption, integrity protection and
> > "we haven't thought of it yet".
> > Because combinatorial explosion is still a Bad Thing for deployment.
> 
> I oppose any fundamental changes to the SASL base spec, other than
> removal
> of rarely used features/mechanisms.  We're having a *very* hard time
> deploying security and the last thing we need to do is mess with
> something
> that's just starting to work. 
> 
> > SASL as I read it is a way to negotiate into a security layer.
> > From my 10.000 foot level, I don't see the great difference between
> > the exchanges
> > 
> > -> STARTTLS          -> AUTHENTICATE TLS
> > <- OK			<- OK
> > ...first byte of TLS negotiation starts here in both cases.....
> 
> SASL's primary use today is to permit use of a non-cleartext client
> authentication mechanisms.  The security layer is not used a lot yet.
> 
> TLS's primary use today is to authenticate the server and provide a
> privacy layer.  Client authentication is rarely used despite being
> widely deployed (in the form of SSL client certificate support).
> 
> The negotiation and framing they use is completely different.  The
> SASL
> negotiation occurs within the app protocol, while the TLS negotiation
> occurs at a lower level invisible to the app protocol.  The SASL
> framing
> uses just simple counted blocks (with a negotiated max size), while
> the
> TLS framing has many complex rules.
> 
> They can't be merged into a single layer without fundamental changes
> to
> one or both.  And their primary design goals were sufficiently
> different
> that I don't see any harm from having both around.
> 
> > ..............actually, why not?
> > the blocking factor I can see is the text in RFC 2222 section 5.3,
> > and we change protocols, don't we?
> 
> I am strongly opposed to any changes to SASL which would stall the
> progression along the standards track.  We need to get security
> deployed
> yesterday, not next year.  It is way too late to change the
> fundamental
> framing mechanisms.
> 
> > But I do NOT think adding compression as a property of a SASL
> > mechanism is going to cut it. Unfortunately.
> 
> How about a new standards track spec which amends SASL in a
> backwards-compatible way so that any SASL mechanism with a security
> layer
> can also negotiate compression? 
> 
> Note that this is *not* important enough in my book to merit a
> non-backwards-compatible change to SASL.  Compression is a nice way to
> use
> spare CPU cycles to save network bandwidth, but it's far from a
> requirement. 
> 
> 		- Chris
> 
> 
>

---

From: "Jack De Winter" <[email-masked]>
Date: Thu, 28 May 1998 17:35:15 -0400

>military, banking or telephone system in the same way.

However, take the following viewpoint:

You have 10,000 users, each dialing in over slow lines to access the
mail servers.  

While I understand your viewpoint, please understand mine.  Why should
compression not be put into a mechanism that has the appropriate framing
and negotiation phases already built in?  Otherwise, we have to come up
with a SCL (Session Compression Layer) that has to be negotiated above
and beyond SASL, make sure that the SASL after SCL is invalid, etc...

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: "Jack De Winter" <[email-masked]>
Date: Thu, 28 May 1998 17:35:15 -0400

regards,
Jack