Skip to main content

IMAP UNAUTHENTICATE Extension for Connection Reuse
RFC 8437

Yes

(Alexey Melnikov)

No Objection

Alvaro Retana
Warren Kumari
(Deborah Brungard)
(Eric Rescorla)
(Ignas Bagdonas)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 00 and is now closed.

Alvaro Retana No Objection

Warren Kumari No Objection

(Adam Roach; former steering group member) Yes

Yes (2018-06-06 for -00)
This mechanism seems useful. Thanks to the author for sticking with it.

I support Martin's comment.

I also have a tiny editorial nit:

§8:

>  The original IMAP state machine was designed to allow a server
>  implementation approach where each IMAP authentication identity
>  matches an operating system identity and the server revokes all
>  administrative privilege onces authentication completes.

Typo: "once"

(Alexey Melnikov; former steering group member) Yes

Yes (for -00)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-06-06 for -00)
I was surprised to see normative language in this text in 4.2 since this behavior is specified elsewhere, not here:

When a TLS [RFC5246] security layer is negotiated either via the
   STARTTLS command or use of the imaps port [RFC6186], IMAP servers MAY
   be configured to request a client certificate and IMAP clients MAY
   provide one.

(Ben Campbell; former steering group member) No Objection

No Objection (2018-06-06 for -00)
§2: There are a few instances of lower case 2119 keywords. Please consider using the boilerplate from RFC 8174 instead.

§4.2, first paragraph, 2nd sentence: The two MAYs seem more like statements of fact rather than new normative permissions.

(Benjamin Kaduk; former steering group member) No Objection

No Objection (2018-06-04 for -00)
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?

(Deborah Brungard; former steering group member) No Objection

No Objection (for -00)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (for -00)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -00)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (2018-06-06 for -00)
Hello,

since you revise the state machine, shouldn't this Document update 3501?

Thank you

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2018-06-04 for -00)
Quick question, however, I really don't know much about IMAP: Would it already help to just use TLS1.3 0-RTT session resumption instead?

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -00)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -00)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -00)