Last Call Review of draft-ietf-extra-jmapaccess-04
review-ietf-extra-jmapaccess-04-secdir-lc-migault-2023-10-12-00

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).

<mglt>
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.  
<mglt>


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.
<mglt>
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.
</mglt>

   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.

<mglt>
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.
</mglt>

   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.
<mglt>
What is the JMAP server has already been explained, and it seems
sufficiently obvious to not repeat it. This is just a nit. 
</mglt>

   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.
<mglt>
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.
</mglt>

[...]

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.

<mglt>
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.
</mglt>