Re: [secdir] Secdir last call review of draft-ietf-extra-imap4rev2-24

[Alexey Melnikov <[e-mail]>]

Hi Daniel,


On 19/01/2021 20:46, Daniel Migault wrote:
> Hi Alexey,
>
> Thanks for your response. Please find some clarifications/responses.
Thank you for the followup. My responses below.
>
> Yours,
> Daniel
>
> ------------------------------------------------------------------------
> *From:* Alexey Melnikov <[e-mail]>
> *Sent:* Tuesday, January 19, 2021 12:46 PM
> *To:* Daniel Migault <[e-mail]>; [e-mail] 
> <[e-mail]>
> *Cc:* [e-mail] 
> <[e-mail]>; [e-mail] 
> <[e-mail]>; [e-mail] <[e-mail]>
> *Subject:* Re: Secdir last call review of draft-ietf-extra-imap4rev2-24
> Hi Daniel,
>
> Thank you for your review. My replies below. I removed some of your
> comments that I need to think a bit more and will reply to them 
> separately.
>
> On 19/01/2021 14:52, Daniel Migault via Datatracker wrote:
> > Reviewer: Daniel Migault
> > Review result: Has Nits
> >
  [snip]
> >
> > [ ... ]
> >
> >     $Phishing  The $Phishing keyword can be used by a delivery agent to
> >        mark a message as highly likely to be a phishing email.  An email
> >        that's determined to be a phishing email by the delivery agent
> >        should also be considered a junk email and have the appropriate
> >        junk filtering applied, including setting the $Junk flag and
> >        placing in the \Junk special-use mailbox (see Section 7.2.3) if
> >        available.
> >        If both the $Phishing flag and the $Junk flag are set, the user
> >        agent should display an additional warning message to the user.
> >        User agents should not use the term "phishing" in their warning
> >        message as most users do not understand this term.  Phrasing of
> >        the form "this message may be trying to steal your personal
> >        information" is recommended.  Additionally the user agent may
> >        display a warning when clicking on any hyperlinks within the
> >        message.
> >
> > <mglt>
> > I tend to believe that phishing is now
> > (unfortunately) known by most users.
> > I have the impression that UI is always a
> > difficult problem, and I am wondering if such
> > recommendations are still valid or if that is
> > a legacy statement. I do not have strong
> > feeling about what to do, so I leave it to
> > you, but is interested in your opinion.
> This text matches the original registration of the $Phishing keyword. I
> have seen some modern email clients still following this advice, so I
> think it is useful. Which part of it do you find outdated?
>
> <mglt>
>
> Just to be clear that was just a comment. In the following sentence,
> """
> User agents should not use the term "phishing" in their warning
> message as most users do not understand this term.
> """
> I was questioning  "as most users do not understand this term" and 
> tend to believe that most users have heard what phishing means. So I 
> am wondering if the user the message is being shown does not translate 
> to itself: "Oh yeah they mean phishing".  Again just some random 
> thoughts from my part.
Sorry, I was staring at this text so much that I stopped noticing it. 
Now that you pointed this out I think removing this sentence makes sense.
>
> </mglt>
  [snip]
> >
> > The section mentions that repeated attempts
> > for a password associated is detected,
> > somehow prevented. It may also worth
> > mentioning that with a large number of login
> > (known or guessed),
> > an attacker may try to guess a login
> > associated to a small number of commonly
> > known weak passwords ( password
> > spraying). I believe it might worth being
> > mentioned, that correlating failed attempts
> > worth also being mentioned.
> Fair enough. Can you suggest some text?
>
> <mglt>
> Maybe something around these lines:
>
> An IMAP server SHOULD report any authentication failure and analyze 
> the attempt with regard to a password brute force attack as well as a 
> password spraying attack. Accounts that matching password spraying 
> attacks MUST be blocked and request to change their passwords and only 
> password with significant strength SHOULD be accepted.
I edited this slightly. Thank you for the suggestion.
> /**/
> </mglt>
>
> > Maybe that goes a bit too far in the purpose
> > of recommendations, but it might may sense to
> > recommend strong random passwords used in
> > conjunction of passwords wallets or the use
> > of mutually authenticate TLS.
> >
> > </mglt>
> >
> >
> > <mglt>
> > One question I would have - and with very
> > little opinion on it - is how vulnerable IMAP
> > parsing is to injection. I usually see the
> > use of JSON as a big advantage toward
> > this, but I would be happy to known
> > your opinion on it.
> Can you give me an example, as I am not sure what do you mean by
> injection in this case?
>
> <mglt>
> I do not have specific example in mind. My question was if there are 
> known ways to inject some commands in a specific field or if some 
> parsers checks have been relaxed to enable interoperability.
I can't think of any. IMAP is either using octet-counted literals or 
strict syntax (LIST-like). Syntax is quite regular and easier than XML 
(IMHO).
>
> </mglt>
>
> > I also have the impression that injections
> > can be performed via the web interface, so a
> > web front end should be carefully considered
> > and IMAP server may not believe they are
> > always immune behind a web front end and
> > still require to follow the best practises.
> >
> > </mglt>
>
> Best Regards,
>
> Alexey
>