Subject: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-unauth-00: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 04 Jun 2018 13:25:22 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap-unauth-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-unauth/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please consider using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate; there
seems to be at least one usage of a lowercase keyword.

I do not remember seeing a response to the secdir review, which raises an issue that is probably
worth addressing (even if it is largely editorial).

I have a few other comments/questions, that happen by chance to all occur within Section 3.

   This command directs the server to reset all connection state, except
   for state at the TLS [RFC5465] layer.

5465 is IMAP NOTIFY, and a short Hamming distance from 5246 (TLS
1.2).  Though I note that TLS 1.3 is in the RFC Editor's queue...

   If a mailbox was selected, the mailbox ceases to be selected but no
   expunge event is generated.  If a SASL [RFC4422] security layer was
   active, it terminates immediately after the server sends the CRLF
   following the OK response.  For the client, it terminates immediately
   after the CRLF following the UNAUTHENTICATE command.

"terminate" applies only to outgoing messages, presumably?  (Should
this be made more explicit?)  A similar thing applies to COMPRESS as
enumerated in Section 4.1.

   Servers MAY choose to advertise the UNAUTHENTICATE capability only
   after authentication has completed.  As a result, clients need to
   issue an IMAP CAPABILITY command after authentication in order to
   determine the availability of UNAUTHENTICATE.

Is this because the ability to reset state may depend on the
authentication mechanism used?

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 07 Jun 2018 14:32:41 -0700

On 4 Jun 2018, at 13:25, Benjamin Kaduk wrote:

> Please refer to for more information about IESG DISCUSS and COMMENT 
> positions.
>
>

Fixed in 01.

> worth addressing (even if it is largely editorial).

Fixed in 01.

> 1.2).

Fixed in 01.

> Though I note that TLS 1.3 is in the RFC Editor's queue...
>

I made an effort to clarify in 01.

> authentication mechanism used?

That's permissible in the model, but the more likely reason is the 
server advertises a minimal set of capabilities prior to authentication 
(which simplifies implementation of a server-side application-layer 
proxy in larger deployment).

		- Chris

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Jun 2018 16:35:23 -0500

> I made an effort to clarify in 01.

Thanks!

> proxy in larger deployment).

Ah, that makes sense.  (I think I did notice a bit about only
advertising the unauthenticate capability after authenticating a
trusted client, later in the document, but forgot to go back and
change my notes -- sorry about that!)

-Benjamin