Subject: Mark Crispin's comments on draft-ietf-sasl-plain-03.txt

From: Rob Siemborski <[email-masked]>
Date: Wed, 29 Oct 2003 19:05:11 -0500 (EST)

Mark had a few comments on the PLAIN draft, mostly centered around the
issue of the initial response examples.  I tend to agree with his
assessments.  I'll note (as Kurt did), that this document has already been
through the WG last call.

a) ACAP is probably not the best choice of protocol for the example, since
it is not in wide use.  A protocol such as SMTP is probably more
appropriate (especially given the trouble we've seen with SMTP
implementations getting initial response handling correct).  SMTP has the
added advantage of having 3 digit response codes that in other have
optional text -- though that is not the case in the SASL challenges.

b) An example demonstrating plain without using the initial response
argument on a protocol that supports it.  This would again help to address
the implementation problems with the optional initial client send.

There are examples in draft-siemborski-rfc2554bis-00.txt (using SMTP) that
satisfy this, and could be used.

One thing that may also help is to place reminders in mechanism (and
protocol) documents that a correct implementation of SASL for a given
protocol requires an understanding of the protocol profile, the SASL
framework, and the mechanism, and that reading all three documents is
necessary to get it right.  Of course, in a perfect world, normative
references would be enough, but experience seems to be showing this not to
be the case.

(I'd also like to encourage people again to read over and comment more
generally on draft-siemborski-rfc2554bis-00.txt and
draft-siemborski-rfc1734bis-00.txt).

We're also both planning on being at the SASL WG meeting in Minneapolis,
and can discuss this further then.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y?
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 29 Oct 2003 23:10:51 -0800

>optional text -- though that is not the case in the SASL challenges.

I think ACAP is a good choice for illustration of SASL/PLAIN
mechanism.  No base64, meaningful protocol tokens (instead of
numeric codes), and a straightforward/simple syntax.  I doubt
developers needs to consult the ACAP specific to understand the
example.

The trouble we've seen with SMTP implementations, I think, make
SMTP a particular bad choice for use here.

>the implementation problems with the optional initial client send.

I have no objection to adding another example.  I'll offer
specific text for the WG to consider in a subsequent post.

>necessary to get it right.

I'll stay on the fence on this one, so I suggest that someone who
currently supports adding such offer specific text for WG
consideration.

Kurt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 29 Oct 2003 23:17:40 -0800 (PST)

On Wed, 29 Oct 2003, Kurt D. Zeilenga wrote:
> numeric codes), and a straightforward/simple syntax.

It is precisely because ACAP does not use BASE64 and does not use numeric
code that makes it unsuitable.  IMAP is also unsuitable.

> SMTP a particular bad choice for use here.

The trouble with SMTP implementation is the *exact* reason why SMTP
examples are needed.  You don't need examples for things that people will
get right.  You need examples for things that people get wrong!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 Oct 2003 01:11:56 -0800

>code that makes it unsuitable.  IMAP is also unsuitable.

The sole purpose of the example is to illustrate the syntax and
semantics described in Section 2 and this purpose is, in my opinion,
best served by avoiding protocol encodings which obfuscate the value
of the message production.

>get right.  You need examples for things that people get wrong!

Some folks have problems getting LDAP/SASL right, so, by your argument,
we should include LDAP-based examples in the PLAIN document.

The trouble with SMTP implementations of SMTP's SASL profile is more
appropriately addressed by revising the SMTP specification.  Attempting
to address these problems in the PLAIN specification might lead to
even more confusion in the SMTP community.

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 30 Oct 2003 09:55:53 -0500

> of the message production.

I tend to agree.  The mechanism docs should only have to worry about the 
order and contents of the exchanges, not how they are encoded or how the 
client-first and server-last issues are handled.

> even more confusion in the SMTP community.

I understand why Mark is proposing more examples (to prevent large 
deployment of incorrect implementations that we all have to deal with), 
but I have to agree with Kurt that the protocol profile is where 
comprehensive examples belong.  RFC 2222[bis] was written so that the 
protocol profiles and mechanism specifications are orthogonal.  In fact, 
the PLAIN doc shouldn't have to worry about whether particular protocols 
support an initial response or not.  RFC 2222bis describes how to handle 
this, and the protocol profile should describe how to implement it.

No matter how you slice it, any good/responsible implementer is going to 
*have* to read three docs.  I think that encouraging/enforcing this 
point is more important than cross-pollinating the docs with the same info.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Mark Crispin <[email-masked]>
Date: Thu, 30 Oct 2003 07:48:27 -0800 (PST)

> point is more important than cross-pollinating the docs with the same info.

Unfortunately, the "good/responsible implementors" do not include the
authors of SMTP SASL for qmail, Microsoft Exchange, or for one of China's
main SMTP servers (smtp.163.net).

People cut corners, skip documents, and make assumptions through empirical
tests with existing implementation.  I wish that the world was not this
way.  It is.

For people with that mindset, the only thing that you need the SMTP SASL
document for is to learn the response codes.  Nothing else needs to be
read.  They don't read 2222 either.  "It works with Netscape and Outlook"
is their rallying call.

I am not of that mindset, but I have spent many weary hours convincing
those who have that mindset that their software is broken.

Clarifying examples are always good.  I understand why you resist
examples; I underwent that myself with the IMAP specification.  The IMAP
specification had to grow enormously to accomodate all the examples that
people insisted upon adding.  But even I have to acknowledge that the
result was better than what was before.

-- Mark --

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Oct 2003 12:00:16 -0500

Hi Ken,

--On Thursday, October 30, 2003 9:55 -0500 Ken Murchison <[email-masked]> 
wrote:

| No matter how you slice it, any good/responsible implementer is going to
| *have* to read three docs.

Its not just three, in fact it is one (SASL), + one per-mechanism, + one 
per-protocol. If you're writing an email client, chances are that's going 
to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case we also 
have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). Each of 
those is slightly different in some way. Multiply that by all the 
mechanisms...

| I think that encouraging/enforcing this point
| is more important than cross-pollinating the docs with the same info.

Again I would like to suggest some kind of "implementer's guide" document 
for SASL that would provide comprehensive examples for each type of 
protocol and each mechanism, as well as a list of the common implementation 
errors that have cropped up. That's not meant to replace having to read and 
understand each of the other documents, but can be used more as a starting 
point for multiple protocol implementations etc.

I would also like to suggest the possibility of an interop event once the 
new docs are out so that we can pin down problems related to the new i18n 
stuff, as well as weed out existing problems. The feedback from that could 
be used in the implementer's guide too.

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Oct 2003 17:10:37 +0000

>result was better than what was before.
Instead of modifying PLAIN, I would rather recommend adding more 
examples to RFC2222bis or create a new draft "SASL Implementation 
Considerations" which contains list of common mistakes and compares 
different profiles.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 Oct 2003 09:43:15 -0800

>read.  They don't read 2222 either.  "It works with Netscape and Outlook"

If they don't read the SASL specification, then any wouldn't read any
examples we'd place there.  I also note that examples are informative
in nature.  It should be possible to independently develop interoperable
implementations without reading any example.

>Clarifying examples are always good.

If placed in the appropriate document and don't get in the way of the
definitive specification, I would accept that non-redundant clarifying
examples are generally good thing.

>I understand why you resist

I think we're resisting attempts to add examples intended to clarify
aspects of protocol which are not specified in this document.  Clarifying
the SMTP, LDAP, IMAP, and other application level protocol specifications
is beyond the scope of this document.

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 30 Oct 2003 12:39:32 -0500

Cyrus Daboo wrote:

> Hi Ken,
> 
> --On Thursday, October 30, 2003 9:55 -0500 Ken Murchison 
> <[email-masked]> wrote:
> 
> per-protocol. If you're writing an email client, chances are that's 

Right.  I was just looking at the SMTP + PLAIN scenario.

> going to be IMAP, POP3 and SMTP, with LDAP a likelihood too. In our case 
> we also have to contend with ACAP, IMSP and ManageSIEVE (and soon BEEP). 
> Each of those is slightly different in some way. Multiply that by all 
> the mechanisms...
> 
> Again I would like to suggest some kind of "implementer's guide" 
> document for SASL that would provide comprehensive examples for each 
> type of protocol and each mechanism, as well as a list of the common 
> implementation errors that have cropped up. That's not meant to replace 
> having to read and understand each of the other documents, but can be 
> used more as a starting point for multiple protocol implementations etc.

I think this is an excellent idea.  I might even be able to volunteer to 
author or co-author such a document.

> I would also like to suggest the possibility of an interop event once 
> the new docs are out so that we can pin down problems related to the new 
> i18n stuff, as well as weed out existing problems. The feedback from 
> that could be used in the implementer's guide too.

Another good idea.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 30 Oct 2003 10:39:29 -0800 (PST)

On Thu, 30 Oct 2003, Kurt D. Zeilenga wrote:
> examples we'd place there.

Exactly.  That's why it has to be in all the relevant documents, in the
hope that the implementor will see the example in the document he chooses
to read.

> I also note that examples are informative

I wish that too; but it is unrealistic.

> is beyond the scope of this document.

PLAIN is a mechanism which can operate in one of two ways, depending upon
whether or not the client supplies initial data.  This applies to all
application protocols that use SASL.  Therefore, this is within the scope
of PLAIN.

The choice of SMTP instead of ACAP is defensible by the fact that there
will be many more SMTP implementations than ACAP implementations.  Also,
SMTP style interaction is much more typical of Internet protocols than
ACAP (or POP3 or IMAP).  NNTP and FTP are other examples of such protocols
that use SASL now (or are likely to in the future).

The fact that a server needs to send something like "334 " (note the
trailing space) and nothing else is non-intuitive and surprising.  It
triggers a "that can't be right" feeling.  Therefore, there needs to be
explicit examples that say, "yes, it is right".

No matter how redundant an example may seem to be, if it prevents a bad
implementation then less harm is done by having the example in the
document.  I regularly deal with individuals who insist that because
explicit text isn't in one particular RFC, the associated requirement
therefore does not exist -- no matter how many normative documents say
otherwise!

This is why RFCs 2821 and 2822 spend a considerable amount of effort
belaboring points that seem to be in the other document's scope.

-- Mark --

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 15:04:03 -0500

>>>>> "Cyrus" == Cyrus Daboo <[email-masked]> writes:

    Cyrus> | I think that encouraging/enforcing this point | is more
    Cyrus> important than cross-pollinating the docs with the same
    Cyrus> info.

    Cyrus> Again I would like to suggest some kind of "implementer's
    Cyrus> guide" document for SASL that would provide comprehensive
    Cyrus> examples for each type of protocol and each mechanism, as
    Cyrus> well as a list of the common implementation errors that
    Cyrus> have cropped up. That's not meant to replace having to read
    Cyrus> and understand each of the other documents, but can be used
    Cyrus> more as a starting point for multiple protocol
    Cyrus> implementations etc.

Why is this preferable to including protocol specific implementation
notes in the protocol profile documents?

--Sam

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 29 Oct 2003 23:10:51 -0800

Kurt

---

From: Mark Crispin <[email-masked]>
Date: Wed, 29 Oct 2003 23:17:40 -0800 (PST)

-- Mark --

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 Oct 2003 01:11:56 -0800

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 30 Oct 2003 09:55:53 -0500

---

From: Mark Crispin <[email-masked]>
Date: Thu, 30 Oct 2003 07:48:27 -0800 (PST)

-- Mark --

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 30 Oct 2003 12:00:16 -0500

Hi Ken,

-- 
Cyrus Daboo

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 30 Oct 2003 17:10:37 +0000

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 30 Oct 2003 09:43:15 -0800

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Thu, 30 Oct 2003 12:39:32 -0500

Another good idea.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 30 Oct 2003 10:39:29 -0800 (PST)

-- Mark --

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Oct 2003 15:04:03 -0500

--Sam