Subject: anyone else on this list?

From: "Jack De Winter" <[email-masked]>
Date: Tue, 18 Mar 1997 23:41:32 -0500

how many people are on this list?

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

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

---

From: Mark Miller <[email-masked]>
Date: Wed, 19 Mar 1997 13:41:27 -0700 (MST)

++count;

Mark.
On Tue, 18 Mar 1997 23:41:32 -0500 Jack De Winter <[email-masked]> 

> how many people are on this list?

----------------------
Mark Miller
[email-masked]

---

From: "Paul E. Hoffman" <[email-masked]>
Date: Wed, 19 Mar 1997 15:22:20 -0800

>how many people are on this list?

Believe it or not, 46. *Someone* out there must have an opinion about SSL
under SASL...

--Paul E. Hoffman, Director
--Internet Mail Consortium

---

From: Mike Macgirvin <[email-masked]>
Date: Wed, 19 Mar 1997 16:32:55 -0800 (PST)

> Believe it or not, 46. *Someone* out there must have an opinion about SSL

Yes, actually, but too busy to respond in depth currently.

I've discussed this offline with John Meyers and Larry Osterman (Microsoft)
several months back. The main protocol issue is the one pointed out in your
earlier message, i.e. framing and the size field. 

The secondary issue, and the reason Netscape isn't pushing real hard on this
right now is the problem of session hijacking. It would be the responsibility
of the _client_ to refuse to fall back on lesser forms of authentication if a
server which was previously known to provide an SSL mechanism all of a sudden
doesn't. (The assumption is the session could be hijacked and a phony
CAPABILITY response returned, minus AUTH=SSL - in the case of IMAP). This puts
the burden on the client to know in advance the supported auth mechanisms. 

It is the prevailing opinion here that this makes the ability to go from
plaintext to "secure" fundamentally flawed.  We are therefore assuming a
reserved port. This actually works quite well in the IMAP model because with
SSLv3 client authentication, we can issue a PREAUTH banner if the client
certificate maps to one we will accept. Otherwise, a normal password login may
be done over the secured channel. 

Another lesser concern is that SSL is primarily a stream protection mechanism,
where client authentication is secondary. This doesn't quite fit the SASL model
which general assumes the opposite. SASL is an authentication mechansim, and
stream protection is secondary. It's also optional, under Kerberos anyway.

SASL also - while providing a list of authentication mechanisms, doesn't allow
one to specify the preferred or perhaps enforced order of them. It also doesn't
map easily onto directory services, where credentials could be mapped to
specific types of authentication. For instance, under LDAP, the "password"
field of the typical inetOrg person typically also defines and includes the
encryption algorithm. For us to announce (again assuming IMAP) a list of
authentication types before knowing the identity of the principal, we may be
providing bogus information because only one type might ulitmately succeed;
that or those which the directory service recognizes for this particular
individual.

In other words, despite SASL's elegance in theory, and with a known subset of
auth services like Kerberos and perhaps GSSAPI and S/KEY, in practice, and once
you step outside those boundaries, it can be a bloody pain in the arse.

/* ==================== PERSONAL OPINION of ======================== */
/* Mike "The MAX" Macgirvin      mailto:[email-masked]             */
/* Postmaster General            http://www.netscape.com/people/max/ */
/* Messaging Server Development  Netscape Communications Corporation */
/* ================================================================= */

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 20 Mar 1997 17:29:28 -0500 (EST)

Mike Macgirvin writes:
> The secondary issue, and the reason Netscape isn't pushing real hard
> on this right now is the problem of session hijacking. It would be the
> responsibility of the _client_ to refuse to fall back on lesser forms of
> authentication if a server which was previously known to provide an
> SSL mechanism all of a sudden doesn't. (The assumption is the
> session could be hijacked and a phony CAPABILITY response returned,
> minus AUTH=SSL - in the case of IMAP). This puts the burden on the
> client to know in advance the supported auth mechanisms. 

> It is the prevailing opinion here that this makes the ability to go
> from plaintext to "secure" fundamentally flawed.  We are therefore assuming
> a reserved port. 

I'm sorry, but this last bit of reasoning is flawed.  A separate port
does not solve this problem.  An active attacker could similarly cause
the attempt to connect to the SSL port to fail with "connection
refused", causing a client to fall back on lesser forms of
authentication on a non-SSL port.

No matter how you slice it, both the server and client are responsible
for having and imposing some policy on the minimum acceptable security
it is willing to use.

> Another lesser concern is that SSL is primarily a stream protection
> mechanism, where client authentication is secondary. This doesn't
> quite fit the SASL model which general assumes the opposite. SASL is
> an authentication mechansim, and stream protection is secondary.
> It's also optional, under Kerberos anyway.

For protocols such as POP/IMAP, client authentication is critical.
Effort spent protecting the stream without addressing the client
authentication problem is misdirected.  You end up with the illusion
of solving the "security" problem without actually having done so.

Solving authentication without stream protection is a relatively weak
quality of security, but it is unfortunately a quality made necessary
by export controls.  It is roughly the same level of quality as doing
stream "protection" with 40-bit crypto.

I'm not trying to bash SSL/TLS; it's got some great engineering in it.
I just want to point out where some of the assumptions/dogma of
current SSL practice are flawed and hopefully engineer the best
solution.

-- 
_.John Gardiner Myers	Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

---

From: Mark Miller <[email-masked]>
Date: Wed, 19 Mar 1997 13:41:27 -0700 (MST)

++count;

Mark.

----------------------
Mark Miller
[email-masked]

---

From: "Paul E. Hoffman" <[email-masked]>
Date: Wed, 19 Mar 1997 15:22:20 -0800

---

From: Mike Macgirvin <[email-masked]>
Date: Wed, 19 Mar 1997 16:32:55 -0800 (PST)

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 20 Mar 1997 17:29:28 -0500 (EST)