Re: [Extra] Secdir last call review of draft-ietf-extra-imap4rev2-24
Alexey Melnikov <alexey.melnikov@isode.com> Wed, 20 January 2021 17:31 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB313A1028; Wed, 20 Jan 2021 09:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HFP6p3DBRt1; Wed, 20 Jan 2021 09:31:19 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D73A0AE8; Wed, 20 Jan 2021 09:31:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1611163877; d=isode.com; s=june2016; i=@isode.com; bh=M8tMXbRgBudrl2UlcRB0PCcw71rntN+ExU926NUd1yw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KuVoDbuCQAC7t0YzRBnpv40snSqvoyKdEGgdGhBlmI4TaRveHE4VjsNRmbCJikhVL6nnDl F6CUoOEQQ8Shx0I9zLak+yfIJaW4bPpl4RX4tPXxQjnIX3s/obS9v4phjQXF/Ed6OWCZln dZ9u6heY+05x+XEGu3ZdFO6MkdlJMWw=;
Received: from [172.27.250.196] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <YAho5ABqmkwt@statler.isode.com>; Wed, 20 Jan 2021 17:31:16 +0000
To: Daniel Migault <daniel.migault@ericsson.com>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "draft-ietf-extra-imap4rev2.all@ietf.org" <draft-ietf-extra-imap4rev2.all@ietf.org>, "extra@ietf.org" <extra@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
References: <161106792581.26552.4563982290675643872@ietfa.amsl.com> <99082ebc-318b-5c4d-a9e6-b3893ab99c0d@isode.com> <DM6PR15MB2379AD34B141FD5015D25E86E3A30@DM6PR15MB2379.namprd15.prod.outlook.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <ecbc01e4-4a84-4a5b-e7be-e87c7897a01c@isode.com>
Date: Wed, 20 Jan 2021 17:31:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
In-Reply-To: <DM6PR15MB2379AD34B141FD5015D25E86E3A30@DM6PR15MB2379.namprd15.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------13083B1379C3450CCE4C04B9"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/MGqlflUY1m7VCfEHzyA5_m3Yy2o>
Subject: Re: [Extra] Secdir last call review of draft-ietf-extra-imap4rev2-24
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2021 17:31:25 -0000
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 <alexey.melnikov@isode.com> > *Sent:* Tuesday, January 19, 2021 12:46 PM > *To:* Daniel Migault <daniel.migault@ericsson.com>; secdir@ietf.org > <secdir@ietf.org> > *Cc:* draft-ietf-extra-imap4rev2.all@ietf.org > <draft-ietf-extra-imap4rev2.all@ietf.org>; extra@ietf.org > <extra@ietf.org>; last-call@ietf.org <last-call@ietf.org> > *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 >
- [Extra] Secdir last call review of draft-ietf-ext… Daniel Migault via Datatracker
- Re: [Extra] Secdir last call review of draft-ietf… Alexey Melnikov
- Re: [Extra] Secdir last call review of draft-ietf… Daniel Migault
- Re: [Extra] Secdir last call review of draft-ietf… Alexey Melnikov
- Re: [Extra] Secdir last call review of draft-ietf… Daniel Migault
- Re: [Extra] Secdir last call review of draft-ietf… Alexey Melnikov
- Re: [Extra] Secdir last call review of draft-ietf… Daniel Migault