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

[Daniel Migault <[e-mail]>]

Thanks for the response!
Yours,
Daniel
________________________________
From: Alexey Melnikov <[e-mail]>
Sent: Wednesday, January 20, 2021 12:31 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,


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]><mailto:[e-mail]>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[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