[Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap4rev2-27: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap4rev2-27: 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-imap4rev2/



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

There are several places where we see a:

   Note: Since this document is restricted to 7-bit ASCII text, it is
   not possible to show actual UTF-8 data.  [...]

But this document is *not* restricted to 7-bit ASCII text!
(I guess the (not-quoted) bit about not being possible to show actual KOI8-R data is
still true, though.)  Showing actual non-ASCII text may not be as
helpful as the current formulation, though, so I'd suggest just a
modification to the disclaimer.

Section 1.3

   IMAP was originally developed for the older [RFC-822] standard, and
   as a consequence several fetch items in IMAP incorporate "RFC822" in
   their name.  In all cases, "RFC822" should be interpreted as a
   reference to the updated [RFC-5322] standard.

It looks like it's down to just one (not "several"), now -- RFC822.SIZE.

Section 2.2.1

      response, and reads another response from the server.  In all
      cases, the client MUST send a complete command (including
      receiving all command continuation request responses and command
      continuations for the command) before initiating a new command.

To check my understanding: the "command continuations for the command"
are things that the client sends, right?  Adding a word or two might
help clarify.

Section 2.3.1.1

                                         A good UIDVALIDITY value to use
   is a 32-bit representation of the current date/time when the value is
   assigned: this ensures that the value is unique and always increases.
   Another possible alternative is a global counter that gets
   incremented every time a mailbox is created.

In light of the discussion in draft-gont-numeric-ids-sec-considerations,
I wonder if these are truly the most recommended options, as either
option has potential to leak some information about rate or time of
mailbox creation.  Leaking the time of mailbox creation to the user who
created it is, of course, not an issue, but not all IMAP mailboxes are
single-user-access.  A 32-bit PRP (e.g., block cipher) applied to either
option would provide some level of obfuscation while preserving the
uniqueness properties.

Section 2.3.2

   $Junk  The user (or a delivery agent on behalf of the user) may
      choose to mark a message as definitely containing junk ($Junk; see
      also the related keyword $NotJunk).  The $Junk keyword can be used
      to mark (and potentially move/delete messages later), group or
      hide undesirable messages.  See [IMAP-KEYWORDS-REG] for more
      information.

I'm not entirely sure what additional information I'm supposed to get
from [IMAP-KEYWORDS-REG]; the registry page is fairly short on
commentary.  (Applies throughout.)

Section 3.2

   In the authenticated state, the client is authenticated and MUST
   select a mailbox to access before commands that affect messages will
   be permitted.  This state is entered when a pre-authenticated
   connection starts, when acceptable authentication credentials have
   been provided, after an error in selecting a mailbox, or after a
   successful CLOSE command.

I think after a successful UNSELECT as well, right?  §6.4.2 says
"returns the server to the authenticated state" about UNSELECT.

Section 3.4

            (6) CLOSE command, unsolicited CLOSED response code or
                failed SELECT or EXAMINE command

[UNSELECT here as well, if above.]

Section 5.1.2.2

   Previous version of this protocol does not define a default server
   namespace.  Two common namespace models have evolved:

nit: maybe "the previous version of this protocol did not define" or
"previous versions of this protocol did not define"

Section 6.1.1

   Other capability names refer to extensions, revisions, or amendments
   to this specification.  See the documentation of the CAPABILITY
   response in Section 7.2.2 for additional information.  No
   capabilities, beyond the base IMAP4rev2 set defined in this
   specification, are enabled without explicit client action to invoke
   the capability.

Should we also note here that even the base IMAP4rev2 set can require
explicit client action to enable (e.g., when IMAP4rev1 is also
advertised)?

Section 6.2

   Server implementations MAY allow access to certain mailboxes without
   establishing authentication.  This can be done by means of the
   ANONYMOUS [SASL] authenticator described in [ANONYMOUS].  [...]

To be clear, from the perspective of the state machine, this entails
entering the "authenticated" state but without actually authenticating
as a specific client identity?

Section 6.2.1

Do we really want the example to show use of LOGIN (which per §6.2.3 is
be considered a "last resort" and SHOULD NOT be used) even when
AUTH=PLAIN is available?

Section 6.2.2

   As with any other client response, this initial response MUST be
   encoded as BASE64.  It also MUST be transmitted outside of a quoted

nit: it looks like we added another paragraph or two between the
previous mention of "initial response" and here, so maybe s/this/the/ is
in order.

      authentication.  (Note that SASL framework allows creation of SASL
      mechanisms that support 2FA (2-factor authentication), however
      none are fully ready to be recommended by this document.)

(side note) With sasl/gssapi/kerberos it's possible to know that the
client used 2fa for its authentication exchange with the KDC even if it
only has the one (ticket) factor to present to the IMAP server.  But
this is probably more detail than we need to get into here...

               C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
               S: A001 OK Success (tls protection)

(nit) A01 is reusing the client tag, and doesn't seem to match the
response ... typo?

Section 6.2.3

   Unless either the client is accessing IMAP service on Implicit TLS
   port [RFC8314], the STARTTLS command has been negotiated or some
   other mechanism that protects the session from password snooping has
   been provided, a server implementation MUST implement a configuration
   in which it advertises the LOGINDISABLED capability and does NOT
   permit the LOGIN command.  [...]

(editorial) Given that there are preconditions based on runtime
behavior, it's a little strange to have it be "MUST implement" in this
manner.  If it's mandatory to use, that's an easy fix, but I suspect
that the intent is only that the server must implement a configuration
where it advertises LOGINDISABLED unless the preconditions are mit,
which seems like a more complicated rewording.

Section 6.3.1

   In the following example, the client enables CONDSTORE:

Should we reference RFC 7162 here?

Section 6.3.2

   fails is attempted, no mailbox is selected.  When deselecting a
   selected mailbox, the server MUST return an untagged OK response with
   the "[CLOSED]" response code when the currently selected mailbox is
   closed (see Paragraph 10).

I'm not sure how to find Paragraph 10.

Section 6.3.5

It kind of looks like the "examples" contains two similar examples stuck
together (or some other client has (re)created some folders
mid-session).  I think in RFC 3501 the blank line separating examples
also crossed a page boundary, so it got missed when converting to XML(?)
for the new document.

Section 6.3.6

   If the server's hierarchy separator character appears in the name,
   the server SHOULD create any superior hierarchical names that are
   needed for the RENAME command to complete successfully.  In other

Is this specifically in the "new mailbox name"?

   the normalized new mailbox name (see Section 6.3.9.7).  This would
   allow the client to correlate supplied name with the normalized name.

nit: "the supplied name".

Section 6.3.9.8

   4:   In this example, we see more mailboxes that reside on another
        server.  This is similar to the command <RLIST "" "%">.

      C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Fruit"
      S: * LIST (\HasNoChildren) "/" "Tofu"
      S: * LIST (\HasChildren) "/" "Vegetable"
      S: * LIST (\Remote) "/" "Bread"
      S: * LIST (\HasChildren \Remote) "/" "Meat"
      S: A04 OK done

Why does "Bread" not give \HasChildren or \HasNoChildren?
I thought §6.3.9.5 said that the server MUST return these attributes
(and the example does show \HasChildren returned for another \Remote
box).

In example 10, "also" doesn't exist and "also/jazz" is remote.  Can we say
anything a priori about whether "also" is remote (the example, of
course, shows that it is not remote)?

Section 6.4.4

   However all options specified above MUST result in a single ESEARCH
   response if used by themselves or in combination.  This guaranty
   simplifies processing in IMAP4rev2 clients.  Future SEARCH extensions

nit: s/guaranty/guarantee/

   MAY be supported.  Clients SHOULD use UTF-8.  Note that if "CHARSET"
   is not provided IMAP4rev2 server MUST assume UTF-8, so selecting

nit: "an IMAP4rev2 server".

Section 6.4.4.4

      Example 4:
               C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
                   NOT FROM "Smith"
               S: P282 OK SEARCH completed
               C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8}
               C: YYYYYYYY

That snippet doesn't seem consistent with a synchronizing literal;
should it be a non-synchronizing literal instead?

Section 6.4.8

   Because of the similarity of MOVE to COPY, extensions that affect
   COPY affect MOVE in the same way.  Response codes listed in
   Section 7.1, as well as those defined by extensions, are sent as
   appropriate.

Who decides what is "appropriate"?  Will everyone come to the same
conclusion?

Section 6.5

   Server implementations MUST NOT send any added (not specified in this
   specification) untagged responses, unless the client requested it by
   issuing the associated experimental command or the ENABLE command
   (Section 6.3.1).

We don't really have much text remaining to describe what the
"associated experimental command" would be, now that the "X<atom>
Command" section is removed.

Section 7.1

   CAPABILITY

         Followed by a list of capabilities.  This can appear in the
         initial OK or PREAUTH response to transmit an initial
         capabilities list.  It can also appear in tagged responses to
         LOGIN or AUTHENTICATE commands.  This makes it unnecessary for
         a client to send a separate CAPABILITY command if it recognizes
         this response.

(and if the implicit capability list is sent in the same
authentication/security-mechanism context as subsequent commands)

   COPYUID

         Followed by the UIDVALIDITY of the destination mailbox, a UID
         set containing the UIDs of the message(s) in the source mailbox
         that were copied to the destination mailbox and containing the
         UIDs assigned to the copied message(s) in the destination
         mailbox, indicates that the message(s) have been copied to the
         destination mailbox with the stated UID(s).

(editorial) Is there one UID set in the response or two (one per
source/destination)?  The following paragraph suggests two, but this one
seems to just say one.

   NOPERM

         The access control system (e.g., Access Control List (ACL), see
         [RFC4314] does not permit this user to carry out an operation,
         such as selecting or creating a mailbox.

nit: missing close paren.

Section 7.1.3

The example doesn't seem to show the tagged BAD usage, and I'm having
trouble convincing myself whether "very long command line" should
qualify for the tagged form or not.

Section 7.2, 7.3

If the section headings are split into server and mailbox status,
respectively, why does the initial intro paragraph still list both
server and mailbox status data in both sections?

Section 7.2.2

   Other capability names indicate that the server supports an
   extension, revision, or amendment to the IMAP4rev2 protocol.  Server
   responses MUST conform to this document until the client issues a
   command that uses the associated capability.

(another instance) should we say anything about "MUST conform to this
document" not applying when the server also advertises IMAP4rev1?

   A server MAY send capabilities automatically, by using the CAPABILITY
   response code in the initial PREAUTH or OK responses, and by sending
   an updated CAPABILITY response code in the tagged OK response as part
   of a successful authentication.  It is unnecessary for a client to
   send a separate CAPABILITY command if it recognizes these automatic
   capabilities.

IIRC, the earlier mention of automatic capabilities said that an
explicit CAPABILITY is still needed for the case when (e.g.)
AUTHENTICATE enables a new security layer.

Section 7.3.4

   [[TBD: describe the most common search data pairs returned.]]

Is this still current?

Section 7.5.2

   ENVELOPE
         [...]
         An address structure is a parenthesized list that describes an
         electronic mail address.  The fields of an address structure
         are in the following order: personal name, [SMTP] at-domain-
         list (source route, obs-route), mailbox name, and host name.

The "obs-route" was not in RFC 3501, is not listed in any published
errata reports, and does not seem to be called out in the list of
changes from RFC 3501 in Appendix E.  This isn't the formal protocol
description, so I guess it's not a breaking change, but I still don't
understand why it's different (presumably just my ignorance...).

   If the server chooses to send unsolicited FETCH responses, they MUST
   include UID FETCH item.  Note that this is a new requirement when
   compared to RFC 3501.

      Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

I guess this is intended to just be a generic FETCH example, but it's a
bit jarring to not see the UID FETCH item in the example right after the
text that mentions a requirement to send it, with no other commentary.

Section 8

   The following is a transcript of an IMAP4rev2 connection on a non TLS
   port.  A long line in this sample is broken for editorial clarity.

More than one line, now.

C:   A001 AUTHENTICATE SCRAM-SHA-256
      biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
S:   + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5s
     RiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYNCg==
C:   Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG
     SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft
     bWl6N0FuZFZRPQ==
S:   + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ==

These correspond quite nicely to (base64'd copies of) the example in RFC
7677, with the exception of the first server line, that includes an
additional CRLF in the decoded data.

Section 9

  body-fld-enc    = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
                    "QUOTED-PRINTABLE") DQUOTE) / string
                    ; Content-Transfer-Encoding header field value.
                    ; Defaults to "7BIT" (as per RFC 2045)
                    ; if not present in the body part.

Is this comment still accurate?

  capability      = ("AUTH=" auth-type) / atom
                      ; New capabilities MUST begin with "X" or be
                      ; registered with IANA in
                      ; a standards-track, an experimental
                      ; or an informational RFC.

Is this comment still accurate?

  capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2"
                    *(SP capability)
                      ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
                      ; and LOGINDISABLED capabilities.
                      ; Servers which offer RFC 1730 compatibility MUST
                      ; list "IMAP4" as the first capability.
                      ; Servers which offer RFC 3501 compatibility MUST
                      ; list "IMAP4rev1" as one of capabilities.

I don't remember us mentioning an "IMAP4" capability in the previous
text, and I definitely remember an assertion that the order in which
capabilities are listed does not have significance, which seems to
conflict with the comment about "IMAP4" as the first capability.

  command-any     = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
                      ; Valid in all states

Is x-command still valid?

  media-basic     = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
                    "FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE)
                    / string)
                    SP media-subtype
                      ; Defined in [MIME-IMT].
                      ; FONT defined in RFC 8081.

Why does only FONT get a comment?  I don't see "MODEL" in [MIME-IMT],
either.

When the namespace-command production is defined, it's spelled all in
lowercase, but it is spelled "Namespace-Command" when it appears in the
command-auth production.

The "partial-range" production doesn't seem to be used anywhere.

  return-option   =  "SUBSCRIBED" / "CHILDREN" / status-option /
                     option-extension

(nit) This seems to only be used in list-return-opts, so maybe the
generic name is not the best fit for it.

Section 11

It might be worth putting in some bromide about how while md5 is used
in the BODYSTRUCTURE response, the usage is not particularly security
relevant and so there is not a vulnerability due to its use.

There are also some forms of DoS attack that we don't say much about
(slowloris, many parallel connections, etc.), and the mitigations are
fairly well known.  It might be worth expounding on these a little bit
(though since in most cases both parties have authenticated in some
manner, the situation is not as bad as it sometimes is).

Section 11.3

      as well as any response codes other than CAPABILITY.  Client
      SHOULD ignore the ALERT response code until after TLS has been
      successfully negotiated (whether using STARTTLS or TLS negotiation
      on implicit TLS port).  Unless explicitly allowed by an IMAP

Up in §7.1 we said that this was "without TLS or SASL security layer
confidentiality", not limited to TLS.
(Also, nit: "Clients" plural.)

Section 11.6

   A server SHOULD report any authentication failure and analyze such
   authentication failure attempt with regard to a password brute force
   attack as well as a password spraying attack.  Accounts that match
   password spraying attacks MUST be blocked and request to change their
   passwords and only password with significant strength SHOULD be
   accepted.

I'm not 100% sure that "password spraying attack" is a well-known
concept.  It probably is, but it's hard to be sure.

Also, I assume that "accounts that match password spraying attacks"
means accounts where the password being tested succeeds at
authenticating, which could be worth clarifying with a wording tweak.

Section 13.1

It's not clear to me that [ANONYMOUS] is referenced in a manner that
requires classification as normative; likewise for [SCRAM-SHA-256].
Similarly, if we use a modified form of [UTF-7] that we describe in
whole ourselves, that does not seem to be normative.

Section 13.2

If we refer to RFC 3503 for more details on how the mechanism is used,
should that be a normative reference?

Appendix E

   29.  Revised IANA registration procedure for IMAP extensions and
        removed "X" convention.

Is that worth a BCP 178 reference?