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