Hi, I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Please find my comments inline. Yours, Daniel draft-ietf-extra-jmapaccess-04 1. Introduction A few IMAP client maintainers have asked for ways to use features that are available in JMAP without having to drop their expensively tested IMAP code. This document provides a server with a way to declare that the messages in its mailstore are also available via JMAP. For simplicity, only a complete equivalence is supported (the same set of messages are available via both IMAP and JMAP). A complete equivalence may not be very clear. At least I think it means that the messages are available in both format IMAP and JMAP, but it could also be read as messages in IMAP and JMAP are fully equivalent which is not the case necessarily as with internationalization the JMAP and IMAP version may differ. 3. Details By advertising the JMAPACCESS capability, the server asserts that if a mailbox or message has a particular object ID when accessed via either IMAP or JMAP (see [RFC3501], [RFC9051] and [RFC8620]), then the same mailbox or message is accessible via the other protocol, and it has the same ID. The way I understand it is that JAMPACCESS can also be used by JMAP client to advertise the existence of an IMAP version. If that is correct the term JMAPACCESS may be a bit surprising. The server MUST also advertise the OBJECTID extension, defined by [RFC8474]. The JMAP session resource that allows access to the same messages is called "the JMAP server" below. This specification does not affect message lifetime: If a client accesses a message via IMAP and half a second later via JMAP, then the message may have been deleted. When the server processes the client's LOGIN/AUTHENTICATE command and enters Authenticated state, the server considers the way the client authenticated. If the IMAP server can infer from the client's authentication process that its credentials suffice to authenticate via JMAP, then the server MUST also send a JMAPACCESS response code containing a link to the JMAP server. If the credentials might not succeed with the JMAP server, then the server SHOULD send an untagged OK response with a DEBUGGING response code with a message to help client developers understand why this authentication would not work with the JMAP server. The way I see this is that DEBUGGING is being used to carry an information that is not yet an error. It is just something informative. What is strange to me, but that has probably been discussed in the working group, is why don't we only send the information when the JAMP session is known not to work. Typically, I would rather expect a scheme like: - if the IMAP server does know JMAP access will not work, then the debugging information is sent. - if we do not know we let the JAMP aces provide the errors. It looks we prefer the client not attend the connection to the JMAP. Maybe the text is saying that JAMPACCESS with the DEBUGGING message as being informative in case a further JAMP session fails. In that case what was unclear to me is that DEBUGGING is sent together with the JAMAPACCESS. Servers are encouraged to report the same message flags and other data via both protocols, as far as possible. This specification does not require mailboxes to have the same name in IMAP and JMAP, even if they share mailbox ID. However, the JMAP specification regulates that, in the text about the name and role properties in [RFC8620] section 2. Note that all JMAP servers support internationalized email addresses (see [RFC6530]). If this IMAP server does not, or the IMAP client does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then there is a possibility that the client receives accurate address fields via JMAP and downgraded fields via IMAP (see (see [RFC6857] and [RFC6858] for examples). 4. The JMAPACCESS and DEBUGGING Response Codes The JMAPACCESS response code is followed by a single link to a JMAP session resource. The server/mailstore at that location is referenced as "the JMAP server" in this document. What is the JMAP server has already been explained, and it seems sufficiently obvious to not repeat it. This is just a nit. The DEBUGGING response code asserts that when used with a status response, the client may safely forward the string argument to the client maintainers. The argument MUST NOT contain any message contents or other personal information. [...] 5. Examples Lines sent by the client are preceded by C:, lines sent by the server by S:. Each example starts with the IMAP banner issued when the client connects, and generally contains only those capabilities required by the example itself, omitting even required capabilities such as OBJECTID, JMAPACCESS and STARTTLS. Example 1. A client connects, sees that SASL OAUTH is available, and authenticates in that way. S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1 C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB The server processes the command successfully. Since it knows that the client used Oauth, and that it and its JMAP alter ego use the same Oauth backend subsystem, the server infers that the (next) access token is just a usable via JMAP as via IMAP. It issues a JMAPACCESS response code in its reply: S: 1 OK [JMAPACCESS https://example.com/jmap] done SASL OAUTH is specified by [RFC7628], and the argument in this example is abbreviated from the more realistic length used in RFC7628. Just to make sure I understand it correctly, I am expecting the client to re-authenticate itself the same way as it does for IMAP to JMAP. In other words, the IMAP authentication is not used to access the JAMP resources. If that were the case, one need to make sure that JMAP resources are accessed via the same IMAP authenticated session - which mau not be trivial. It might be simpler to have the JMAP and IMAP doing their own authentication. I think this needs to be clarified. [...] 7. Security Considerations DEBUGGING reveals to clients why they cannot auhenticate to the JMAP server. One normally does not want to reveal anything about why a client cannot authenticate, for fear of giving useful information to an intruder. However, in this case the client has already authenticated via IMAP. By doing so the client already gained access to all of the same mail. The authors believe that the debugging value of the response code far outweighs its security concerns. I am assuming that client to server are protected by TLS. What is not very clear to me is how authentication is performed on the JMAP server.