Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10

Phillip Hallam-Baker <hallam@gmail.com> Fri, 14 February 2014 00:46 UTC

Return-Path: <hallam@gmail.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 1B74A1A0007 for <secdir@ietfa.amsl.com>; Thu, 13 Feb 2014 16:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 oe34oH-KHCAP for <secdir@ietfa.amsl.com>; Thu, 13 Feb 2014 16:46:41 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 17CDC1A0006 for <secdir@ietf.org>; Thu, 13 Feb 2014 16:46:40 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id u14so8824704lbd.15 for <secdir@ietf.org>; Thu, 13 Feb 2014 16:46:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h33hTDpLf9vLKLLkf2lkm5jF7BniY+Ib3MpSSvEQsFU=; b=sPIjxIIWFqFHJbQCHoULWS1c/mzZlbJKkYJMoMwSkmsZsYa2BDO0K8svAW6QuHIsWt LNFC6e4x4fDS/ZpEBzGgWrXnOvslIXbmb7ip/RXTMg5WB2U2ZIFWHDNTgxa1hmSWG7XB kL3kjfS5prCfbASHn1XySIotGHi+3TupqCXR+ibfr+/wWznXPNuYYFdANwsgIKiyGcJ/ eXrcWgMSjNjtdPizgbAUn+vXVO/ZXcCd2geBVmBveHKn/42mydqvpqmMqxmQ27cE+mL8 7sSRn4T34IMBrW8bRucOLamtPS/VxPYDeaIJKY81umLHx2M6YGnr6HHz2x4TMiuwhLRY h11Q==
MIME-Version: 1.0
X-Received: by 10.112.125.225 with SMTP id mt1mr2706115lbb.35.1392338799029; Thu, 13 Feb 2014 16:46:39 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Thu, 13 Feb 2014 16:46:38 -0800 (PST)
In-Reply-To: <CAMm+LwhWJ2Csb0V3ymvULscfRuxDkuF11FRBbFv4Bt_2LqZFbQ@mail.gmail.com>
References: <CAMm+LwhWJ2Csb0V3ymvULscfRuxDkuF11FRBbFv4Bt_2LqZFbQ@mail.gmail.com>
Date: Thu, 13 Feb 2014 19:46:38 -0500
Message-ID: <CAMm+LwjqmMtdCr4sq+gO2g-Cvp3VLG_PFwRXaCXtegJ9u1CDsw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="089e0112bfb885f2d704f2532385"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/DZt5x2Y8OZ8r60NPgltjC8tgekQ
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: Fri, 14 Feb 2014 00:46:44 -0000

Hit send prematurely


On Thu, Feb 13, 2014 at 7:31 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

>
>   I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> 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.
>
>
>
Such an important protocol needs a full security review. Commenting on how
an extension might affect the protocol seems rather pointless/ineffective
when the original protocol has not been reviewed and raises serious security
concerns.

-- 
Website: http://hallambaker.com/