secdir review of draft-ietf-imapext-sort-19

I have 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 editors and WG chairs should treat these comments just
like any other last call comments.

0. note: the document expired today
1. editorial COMMENTS:
- I ran idnit and received three errors and two warnings. Considering
the long life time of this draft this might be natural, but still at
least the errors must be resolved.
- the document should have a proper TOC and proper page headers and
footers.
- the document uses a "work in progress" document as a normative(!)
reference [UNICASEMAP]. It should be changed to informative or the draft
should not proceed to proposed standard until the reference is stable.
- additionally a HTML link is cited inside the I-D for the informative
reference [THREADING], maybe this reference can be published somewhere
more stable too?
- in the document are several cases with double blanks between
sentences. This is not good and should be removed by the authors or the
editor before publication.

2. COMMENT section 3 - REFERENCE
refers to a product version ("Netscape Mail and News" versions 2.0
through 3.0) which I would consider bad style or even inappropriate for
a proposed standard. Consider the time in the future that this standard
might be valid and that people may not recall a specific product name or
version.

3. COMMENT on section 3 - ORDEREDSUBJECT
A Note refers to former outdated I-D version. I would recommend to
remove any reference to outdated and no longer valid I-Ds.

4. COMMENT (some of this may at the discretion of the AD also be a
DISCUSS) is section 6 Security Considerations:
4.1. you should not only state the deficiencies of IMAP, but also at
least require with a "SHOULD" the authentication of commands and
protection of data on the wire via encryption (e.g. TLS).
4.2. you should mention that using sorting by reference/thread can lead
to wrong references (trees) if more than one email exists with the same
ID (UID/message-sequence/...) and child-messages are grouped to a
father-message. An attacker might use the fact that these values are not
well protected and the sorting algorithm reaction to such ambiguity to
hide messages respectively sorting (relocating) them to a different thread.
4.3. the pre-sorting stripping of the subject of all re and fw headers
to identify the base subject (described in section 2.1) may lead to
actually loosing the right context (end in the worng sorting thread
and/or level) if emails are created where the specified magic letters
are legitimate text at the beginning of the subject. For example in a
foreign language the text "RE" might not be used for reply but actually
have a different real meaning.  

Best regards, Tobias

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf