Subject: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-imap4rev2-26: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 02 Feb 2021 07:15:26 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-extra-imap4rev2-26: 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:
----------------------------------------------------------------------

** Section 1.3.  What are the “unpublished IMAP2bis protocols”?  Even if there
were unpublished, is there any pointer/reference that can be provided, say like
https://tools.ietf.org/html/draft-ietf-imap-imap2bis-02?

** Section 2.3.1.1.  Step #4.  Should “In particular, the internal date,
[RFC-5322] size, envelope, body structure, and message texts (all BODY[...]
fetch data items) must never change)”, use the normative “MUST never change”?

** Section 2.3.3.  The text for $Forwarded notes that “Once set, the flag
SHOULD NOT be cleared.”  Should the same guidance apply to $MDNSent?

** Section 5.1.2.  Editorial.  s/manager to grant to their secretary access
rights/manager to grant to their administrative support staff access rights/

** Section 6.3.1.  Per “However, servers cannot send those unsolicited
responses (with the exception of response codes (see Section 7.1) included in
tagged or untagged OK/NO/BAD responses, which can always be sent) until they
know that the clients support such extensions and thus won't choke on the
extension response data”, what is the more precise definition of “choke” here. 
Is it that the client doesn’t understand the extension or that it won’t be able
to process it?

** Section 6.3.9.3.  Step 3.  Per “Attributes returned in the same LIST
response must be treated additively”, should this be a normative “MUST”?

** Section 6.3.12 and Section 8.  The examples here have a few “non example”
domains (e.g., @Blurdybloop.com, @owatagu.siam.edu, @cac.washington.edu)

** Section 6.4.4.4.  Editorial.  In this section the inline annotation of the
C: and S: examples are with a “//”.  In Section 6.3.10, these annotations are
made via “< … >”.  I’d recommend consistency.

** Section 7.1.  Other than a clear text connection, under what circumstances
would PRIVACYREQUIRED be returned?  I ask because the statement “The operation
is not permitted due to a lack of privacy” seems rather generic and might
benefit from tighter scoping of what “lack of privacy” means.

** Section 7.1.4.  Per “For this reason PREAUTH response SHOULD only be
returned by servers on connections that are protected by TLS (such as on
implicit TLS port [RFC8314]) or protected through other means such as IPSec”,
what is the corner case in mind that motives a SHOULD (instead of a MUST)?

** Section 11.  There are both confidentiality and integrity issues with
sending of IMAP in the clear.

OLD
IMAP4rev2 protocol transactions, including electronic mail data, are
sent in the clear over the network unless protection from snooping is
negotiated.

NEW
IMAP4rev2 protocol transactions, including electronic mail data, are sent in
the clear over the network exposing them to possible eavesdropping and
manipulation unless protections are negotiated.

** Section 11.1.  Per “Other TLS cipher suites recommended in RFC 7525 are
RECOMMENDED …”, seems as if RFC7525 needs to be an explicit reference.

** Section 11.2.  Per “For this reason, IMAP4rev2 clients SHOULD try both ports
993 and 143 (and both IPv4 and IPv6) concurrently by default, unless overriden
[sic] by either user configuration or DNS SRV records [RFC6186]”, is there any
further guidance needed here to guide if say both 993 and 143 respond; or you
get responses across address families?

** In the spirit of inclusive language, consider something like the following:

-- Section 6.2.1.  s/to protect against man-in-the-middle attackers which
alter/to protect against an on-path attacker which could alter/

-- Section 11.1
OLD
… as presented in the server Certificate message, in order to prevent
man-in-the-middle attacks.

NEW
… as presented in the server Certificate message, in order to prevent on-path
attackers attempting to masquerade as the server.

-- Section 11.3.  s/(or a man-in-the-middle attacker)/ (or an on-path attacker)/

** Typos:
-- Section 11.2. s/overriden/overridden/

** From idnits:
  -- The draft header indicates that this document obsoletes RFC3501, but the
     abstract doesn't seem to mention this, which it should.

  -- There are a number of reference warnings which should be confirmed as not
  being problematic (not mentioned in the shepherd write-up)

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 2 Feb 2021 17:08:15 +0000

Hi Roman,

Thank you for your comments. Replying to most of your comments (I will 
reply to the rest separately):

> https://tools.ietf.org/html/draft-ietf-imap-imap2bis-02?
Yes, this looks like a reasonable informative reference.
> fetch data items) must never change)”, use the normative “MUST never change”?
Sure.
> SHOULD NOT be cleared.”  Should the same guidance apply to $MDNSent?
$MDNSet description points to RFC 3503, which states "MUST NOT be 
cleared". I would rather not copy the text into this draft, if that is 
Ok with you?
> rights/manager to grant to their administrative support staff access rights/
Ok.
> Is it that the client doesn’t understand the extension or that it won’t be able
The former. I think it was intended as a shortcut for "crash and 
misbehave in other surprising ways".
> response must be treated additively”, should this be a normative “MUST”?
I think MUST is going to be a bit silly here, as the whole set is 
specified in a single LIST response. I will change this to "are treated 
additively".
> domains (e.g., @Blurdybloop.com, @owatagu.siam.edu, @cac.washington.edu)
Yes, this comes from RFC 3501. I can change these if this is a big deal 
to people, but this will cause literal size changes in various places, 
so this is more work than just search & replace everywhere in the document.
> made via “< … >”.  I’d recommend consistency.

Ok. Murray has pointed out the same thing. I will discuss with RFC 
Editor about the best way of representing comments.

  [snip]

> what is the corner case in mind that motives a SHOULD (instead of a MUST)?
I was thinking about loopback interface or something like Unix domain 
socket (the latter is technically out of scope for this document).
> manipulation unless protections are negotiated.
I used your text, thank you.
> RECOMMENDED …”, seems as if RFC7525 needs to be an explicit reference.

Good point. Added.

  [snip]

> attackers attempting to masquerade as the server.
Changed, thank you.
> -- Section 11.3.  s/(or a man-in-the-middle attacker)/ (or an on-path attacker)/
Changed.
> -- Section 11.2. s/overriden/overridden/
Fixed, thanks.
>    being problematic (not mentioned in the shepherd write-up)

Will do. I think all of them were covered by the IETF LC announcement, 
but I will double check.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 2 Feb 2021 17:26:43 +0000

Hi Roman,

Replying to one more comment:

On 02/02/2021 15:15, Roman Danyliw via Datatracker wrote:
> would PRIVACYREQUIRED be returned?
That is it.
> I ask because the statement “The operation

I changed "privacy" to "data confidentiality". Do you think this is 
clear enough now?

Best Regards,

Alexey

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 2 Feb 2021 18:50:54 +0000

Hi Alexey!

> -----Original Message-----
> From: Alexey Melnikov <[email-masked]>
> Sent: Tuesday, February 2, 2021 12:27 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-extra-
> [email-masked]; [email-masked]
> Subject: Re: [Extra] Roman Danyliw's No Objection on draft-ietf-extra-
> imap4rev2-26: (with COMMENT)
> 
> Hi Roman,
> 
> > ** Section 7.1.  Other than a clear text connection, under what
> > circumstances would PRIVACYREQUIRED be returned?
> That is it.
> > I ask because the statement “The operation is not permitted due to a
> > lack of privacy” seems rather generic and might benefit from tighter
> > scoping of what “lack of privacy” means.
> 
> I changed "privacy" to "data confidentiality". Do you think this is clear enough
> now?

Indeed.  Thanks for making the change.

Roman

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 2 Feb 2021 18:58:24 +0000

Hi Alexey!

Thanks for the quick turn around with all of the edits and the few places where you explained that a changed isn't appropriate.  A bit more inline ...

> From: iesg <[email-masked]> On Behalf Of Alexey Melnikov
> Sent: Tuesday, February 2, 2021 12:08 PM
> Thank you for your comments. Replying to most of your comments (I will reply
> to the rest separately):
> 
> > ** Section 1.3.  What are the “unpublished IMAP2bis protocols”?  Even
> > if there were unpublished, is there any pointer/reference that can be
> > provided, say like https://tools.ietf.org/html/draft-ietf-imap-imap2bis-02?
> > ** Section 2.3.1.1.  Step #4.  Should “In particular, the internal
> > date, [RFC-5322] size, envelope, body structure, and message texts
> > (all BODY[...] fetch data items) must never change)”, use the normative
> “MUST never change”?
> Sure.

Thanks.

> > ** Section 2.3.3.  The text for $Forwarded notes that “Once set, the
> > flag SHOULD NOT be cleared.”  Should the same guidance apply to
> $MDNSent?
> cleared". I would rather not copy the text into this draft, if that is Ok with you?

I hadn't actually checked RFC3503.  If that's in there, no need to repeat here.

> > ** Section 5.1.2.  Editorial.  s/manager to grant to their secretary
> > access rights/manager to grant to their administrative support staff
> > access rights/
> Ok.
> > responses (with the exception of response codes (see Section 7.1)
> > included in tagged or untagged OK/NO/BAD responses, which can always
> > be sent) until they know that the clients support such extensions and
> > thus won't choke on the extension response data”, what is the more precise
> definition of “choke” here.
> > Is it that the client doesn’t understand the extension or that it
> > won’t be able to process it?
> The former. I think it was intended as a shortcut for "crash and misbehave in
> other surprising ways".

Ok.

> > ** Section 6.3.9.3.  Step 3.  Per “Attributes returned in the same
> > LIST response must be treated additively”, should this be a normative
> “MUST”?
> I think MUST is going to be a bit silly here, as the whole set is specified in a
> single LIST response. I will change this to "are treated additively".
> Yes, this comes from RFC 3501. I can change these if this is a big deal to people,
> but this will cause literal size changes in various places, so this is more work
> than just search & replace everywhere in the document.
> > C: and S: examples are with a “//”.  In Section 6.3.10, these
> > annotations are made via “< … >”.  I’d recommend consistency.
> 
> Ok. Murray has pointed out the same thing. I will discuss with RFC Editor about
> the best way of representing comments.

Ok.

>   [snip]
> 
> > ** Section 7.1.4.  Per “For this reason PREAUTH response SHOULD only
> > be returned by servers on connections that are protected by TLS (such
> > as on implicit TLS port [RFC8314]) or protected through other means
> > such as IPSec”, what is the corner case in mind that motives a SHOULD
> (instead of a MUST)?
> I was thinking about loopback interface or something like Unix domain socket
> (the latter is technically out of scope for this document).
> > ** Section 11.  There are both confidentiality and integrity issues
> > with sending of IMAP in the clear.
> >
> > OLD
> > sent in the clear over the network exposing them to possible
> > eavesdropping and manipulation unless protections are negotiated.
> > ** Section 11.1.  Per “Other TLS cipher suites recommended in RFC 7525
> > are RECOMMENDED …”, seems as if RFC7525 needs to be an explicit
> reference.
> 
> Good point. Added.
> 
>   [snip]
> 
> > -- Section 6.2.1.  s/to protect against man-in-the-middle attackers
> > which alter/to protect against an on-path attacker which could alter/
> >
> > -- Section 11.1
> > OLD
> > on-path attackers attempting to masquerade as the server.
> Changed, thank you.
> Will do. I think all of them were covered by the IETF LC announcement, but I
> will double check.

Thanks for all of the above changes.

Regards,
Roman

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Feb 2021 17:48:48 +0000

Hi Roman,

Replying to to the rest of your comments:

> get responses across address families?

I think I would like to stick the Happy Eyeballs reference here: RFC 
8305 (Happy Eyeballs Version 2: Better Connectivity Using Concurrency).

Best Regards,
Alexey

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 11 Feb 2021 14:12:40 +0000

Hi Alexey!

> Sent: Wednesday, February 10, 2021 12:49 PM
> > 993 and 143 (and both IPv4 and IPv6) concurrently by default, unless
> > overriden [sic] by either user configuration or DNS SRV records
> > [RFC6186]”, is there any further guidance needed here to guide if say
> > both 993 and 143 respond; or you get responses across address families?
> 

Makes sense to me.

Regards,
Roman