Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10
Alexey Melnikov <alexey.melnikov@isode.com> Wed, 19 February 2014 12:30 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4F1A0487 for <secdir@ietfa.amsl.com>; Wed, 19 Feb 2014 04:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
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 fSiUyZ1aDDlt for <secdir@ietfa.amsl.com>; Wed, 19 Feb 2014 04:30:45 -0800 (PST)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5619D1A047F for <secdir@ietf.org>; Wed, 19 Feb 2014 04:30:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1392813038; d=isode.com; s=selector; i=@isode.com; bh=cdANPkWz7LXUDVN2XuSVuKXm0iRvKt2gLaCGUioaqGY=; 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=WKesWANJRub9q6xQQJcKEEduiWjpq+YRJEUOn2kyjUcfqwco9kVSmjCc2UUqeSVo7Z5ENE 79jPRJFl/D+GowAwR19tkFbEvEL+BLDbQarbAv3o9cGCzDwGBHM6qae/bof4Uzhknlt0yT VGS5oBmUoT30enm9gXoZA0vQi5FOq1Q=;
Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UwSj7QBvgSMw@statler.isode.com>; Wed, 19 Feb 2014 12:30:38 +0000
Message-ID: <5304A3F2.5070107@isode.com>
Date: Wed, 19 Feb 2014 12:30:42 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
To: Phillip Hallam-Baker <hallam@gmail.com>, Jeffrey Hutzelman <jhutz@cmu.edu>
References: <CAMm+LwhWJ2Csb0V3ymvULscfRuxDkuF11FRBbFv4Bt_2LqZFbQ@mail.gmail.com> <1392341826.4569.14.camel@destiny.pc.cs.cmu.edu> <CAMm+LwjdmJ_c3dVApnuCzsB6VfY_qut2NN-Y=2OWPdLve=TN-w@mail.gmail.com>
In-Reply-To: <CAMm+LwjdmJ_c3dVApnuCzsB6VfY_qut2NN-Y=2OWPdLve=TN-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------010308000809040203090408"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LEmfbhSaUp4KryglBQ02rbdGyz0
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 12:30:48 -0000
Hi Phillip, On 14/02/2014 02:20, Phillip Hallam-Baker wrote: > On Thu, Feb 13, 2014 at 8:37 PM, Jeffrey Hutzelman <jhutz@cmu.edu > <mailto:jhutz@cmu.edu>> wrote: > > On Thu, 2014-02-13 at 19:31 -0500, Phillip Hallam-Baker wrote: > > > > We have a problem here, the security considerations in the draft are > > a back reference to the original protocol. This is the security > references > > section of IMAP, a core Internet protocol in their entirety: > > > > 11 <http://tools.ietf.org/html/rfc3501#section-11>. Security > Considerations > > > > IMAP4rev1 protocol transactions, including electronic mail > data, are > > sent in the clear over the network unless protection from > snooping is > > negotiated. This can be accomplished either by the use of > STARTTLS, > > negotiated privacy protection in the AUTHENTICATE command, or > some > > other protection mechanism. > > Nope. That's the entirety of the _introduction_ to the security > considerations section in RFC33501. It is followed by two subsections > which give a fairly detailed treatment of issues related to > authentication, connection security, and handling of passwords. > > That's not to say the security considerations in the IMAP spec are > complete and perfect; they're certainly not. For example, there is no > discussion of authorization and access control. However, > incomplete is > not the same as nonexistent, and there is no need here to be alarmist. > > > Weird and I was looking for it.. > > There is a problem in that it does not state what the attack model is. > It seems as if the attack model is limited to a passive attack. > > If there is an active MITM attack, SSL will only provide protection if > the server certificate is authenticated. Otherwise, passing the > username and password enclair is problematic. Thank you for your review. As this extension doesn't change authentication model or how TLS services are used, I don't think this is the right document to talk about passive monitoring, passwords or TLS server certificate verification. So I believe the Security Considerations as stated is correct. Best Regards, Alexey
- [secdir] SECDIR Review of draft-ietf-qresync-rfc5… Phillip Hallam-Baker
- Re: [secdir] SECDIR Review of draft-ietf-qresync-… Phillip Hallam-Baker
- Re: [secdir] SECDIR Review of draft-ietf-qresync-… Jeffrey Hutzelman
- Re: [secdir] SECDIR Review of draft-ietf-qresync-… Phillip Hallam-Baker
- Re: [secdir] SECDIR Review of draft-ietf-qresync-… Jeffrey Hutzelman
- Re: [secdir] SECDIR Review of draft-ietf-qresync-… Alexey Melnikov