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

Jeffrey Hutzelman <> Fri, 14 February 2014 02:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B86721A0040 for <>; Thu, 13 Feb 2014 18:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gC374qIywTa7 for <>; Thu, 13 Feb 2014 18:30:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F2B311A0016 for <>; Thu, 13 Feb 2014 18:30:52 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.6/8.13.6) with ESMTP id s1E2UnR8009326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 21:30:49 -0500 (EST)
Message-ID: <>
From: Jeffrey Hutzelman <>
To: Phillip Hallam-Baker <>
Date: Thu, 13 Feb 2014 21:30:49 -0500
In-Reply-To: <>
References: <> <> <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.4-0ubuntu1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on
Cc: "" <>,
Subject: Re: [secdir] SECDIR Review of draft-ietf-qresync-rfc5162bis-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 02:30:55 -0000

On Thu, 2014-02-13 at 21:20 -0500, Phillip Hallam-Baker wrote:

> 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.

Not at all.  It's just a 10+ year old document that doesn't spell things
out very well.

> 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.

Indeed.  Section 11.1 goes into a fair amount of detail about verifying
the server hostname found in the certificate, but says nothing about
validation of the certificate itself.  This is an omission which I like
to think the IETF has been more careful about in more recent documents.

At the time, I think it was somehow assumed that if you used TLS then
_of course_ you would do certificate validation, and in fact probably
your TLS library would do it for you.  Again, these days I like to think
we know better.

In any case, if you think it's worth spending time on a better treatment
of security considerations for IMAP, feel free.  I have no time for
that, and Tero is breathing down my neck about old reviews I still
haven't done. :-(

-- Jeff