IMAP UNAUTHENTICATE Extension for Connection Reuse
RFC 8437
Yes
No Objection
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
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
(Alissa Cooper; former steering group member) No Objection
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
§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
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
(Eric Rescorla; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
Hello, since you revise the state machine, shouldn't this Document update 3501? Thank you
(Mirja Kühlewind; former steering group member) No Objection
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
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection