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

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Feb 2014 19:31:01 -0500

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.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Feb 2014 19:46:38 -0500

Hit send prematurely

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 13 Feb 2014 20:37:06 -0500

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

-- Jeff

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Feb 2014 21:20:18 -0500

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 13 Feb 2014 21:30:49 -0500

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 Feb 2014 12:30:42 +0000

Hi Phillip,

On 14/02/2014 02:20, Phillip Hallam-Baker wrote:
> On Thu, Feb 13, 2014 at 8:37 PM, Jeffrey Hutzelman <[email-masked] 
> <mailto:[email-masked]>> 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.
>
> 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