Hi Daniel,
On 19/01/2021 20:46, Daniel Migault
wrote:
Thank you for the followup. My responses below.Hi Alexey,
Thanks for your response. Please find some clarifications/responses.
[snip]
Yours,
Daniel
From: Alexey Melnikov <alexey.melnikov@xxxxxxxxx>
Sent: Tuesday, January 19, 2021 12:46 PM
To: Daniel Migault <daniel.migault@xxxxxxxxxxxx>; secdir@xxxxxxxx <secdir@xxxxxxxx>
Cc: draft-ietf-extra-imap4rev2.all@xxxxxxxx <draft-ietf-extra-imap4rev2.all@xxxxxxxx>; extra@xxxxxxxx <extra@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24Hi 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
>
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.>
> [ ... ]
>
> $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.
[snip]
</mglt>
I edited this slightly. Thank you for the suggestion.>
> 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 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>
> 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.
</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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
