Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 19 August 2011 11:20 UTC
Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7JBKx50017771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2011 04:20:59 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p7JBKxlL017770; Fri, 19 Aug 2011 04:20:59 -0700 (MST) (envelope-from owner-ietf-pop3ext@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7JBKvcF017764 for <ietf-pop3ext@imc.org>; Fri, 19 Aug 2011 04:20:58 -0700 (MST) (envelope-from alexey.melnikov@isode.com)
Received: from [188.29.207.116] (188.29.207.116.threembb.co.uk [188.29.207.116]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Tk5HMgALhJkr@rufus.isode.com>; Fri, 19 Aug 2011 12:21:23 +0100
Message-ID: <4E4E472A.8030709@isode.com>
Date: Fri, 19 Aug 2011 12:21:14 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Chris Newman <chris.newman@oracle.com>
CC: Mykyta Yevstifeyev <evnikita2@gmail.com>, ietf-pop3ext@imc.org
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90>
In-Reply-To: <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>
Hi Chris, My personal replies are (without consulting with Mykyta): Chris Newman wrote: >> From a technical viewpoint, I have two suggestions: > > Add to section 2.1: > > Servers that lack configuration to accept an X.509 client certificate > for > authentication purposes MUST NOT send a CertificateRequest handshake > to the client > during TLS negotiation. I am wondering whether this is actually possible to enforce using existing TLS stacks. I would rather not make this a MUST NOT level requirement if there are no APIs for this in, for example, OpenSSL. > Also in section 2.1: > > OLD: > SHALL use some other way to identify itself, e.g. USER and PASS > commands. > NEW: > MAY close the connection or try a different authentication mechanism > (e.g., USER > and PASS commands). > It's a spec error to disallow a client configuration that requires use > of client certificate authentication. For high security sites, a > password fallback is not acceptable. Yes, good point. > There are two general editorial problems: 1. issues that might cause > problems during last call. 2. the text could be simplified in several > places. > > Here are some editorial suggestions: > > In Abstract, OLD: > This document specifies how the Post Office Protocol, Version 3 > (POP3) may be secured with Transport Layer Security (TLS) protocol, > by establishing TLS layer connection directly before POP3 > transaction. It updates RFC 1939 and RFC 2595. > NEW: > This document specifies use of Transport Layer Security (TLS) on > port 995 to protect Post Office Protocol, Version 3. It updates RFC > 2595. > > Discussion: This no longer changes any rules in RFC 1939, so I see no > reason to update that specification -- perhaps best to avoid the > debates about "does this update spec XXX?" and "what does it mean for > a proposed standard to update a full standard?" during last call. I am Ok with this change. > Introduction (simplify) NEW: > The Post Office Protocol version 3 (POP3) [RFC1939], is an > application-layer protocol used by local e-mail clients to retrieve > e-mail from a remote server over a TCP/IP connection. It supports > a simple download-and-delete model for access to remote > mailboxes (also called a maildrop). > > As POP3 transfers sensitive information, there is a need > for privacy protection. Transport Layer Security (TLS) [RFC5246] and > its deprecated predecessor Secure Sockets Layer (SSL) [RFC6101] are > commonly > used for this purpose. > > [Discussion: I believe it's incorrect to state POP3 was intended to be > in the clear -- I recall someone, perhaps Marshall Rose telling me the > intention was to use whatever privacy mechanism the lower layers > defined (e.g. IPsec). SSL/TLS became necessary because IPsec wasn't > sufficiently deployable. Also it's inaccurate to say TLS is the only > mechanism -- that will just annoy security geeks during last call who > have used KPOP and IPsec]. Ok. > Two mechanisms to protect POP3 using TLS have been deployed. One > negotiates > TLS within POP3 (also known as upgrading to TLS) [RFC2595]. The other > starts TLS prior to starting the POP3 application layer. The latter > mechanism (called "POP3S" throughout this document) has not been > previously > specified in an RFC. This document specifies POP3S. > > RFC 6186 [RFC6186] specifies use of DNS SRV records [RFC2782] > to locate email access services. It supports both POP3S and POP3 > upgraded > to TLS. For more information, refer to Section 3.3 of RFC 6186. > > Section 2.1: > > to verify server's certificate. Upon successful negotiation all data > ^ > the > ... > SASL EXTERNAL mechanism, which is defined in Appendix A of RFC 4422 > ^ > the > > authentication using X.509 certificate MUST support SASL EXTERNAl > ^^^^^^^^^^^ ^^^^^^^^ > certificates EXTERNAL > > > convention on using X.509 certificate for authentication, the client > ^^^^^^^^^^^ > certificates Yes. > Suggest removing this: > Anyway, as soon as the client authenticates itself, and the server > verifies its credentials, they both enter TRANSACTION state and begin > exchanging POP commands and replies. > or rewording as: > As with POP3, POP3S enters TRANSACTION state after the server sends > a +OK response to an authentication command. I like your rewording. > OLD: > Please note that per RFC 6176 [RFC6176], neither clients nor servers > must perform attempts to negotiate use of SSL 2.0. > NEW: > SSL 2.0 MUST NOT be used for POP3S, see RFC 6176 [RFC6176] for details. Ok. > Section 2.3: > > terminate its part of connection without waiting a response from the > ^ > for > Section 2.4 (simplify): > > POP3S uses port 995. Section 4 updates the IANA registration for > port 995. > > Section 2.5 (simplify/clarify): > > Section 7 of RFC 2595 [RFC 2595] expresses concerns about use of a > separate > port. The concern about port usage does not apply as port 995 was > previously > registered. RFC 6186 mitigates the other concerns. The usefulness of > POP3S > outweighs the mitigated flaws so the statement in section 7 of RFC 2595 > discouraging use of pop3s is rescinded. > > Discussion: this makes it is clear why RFC 2595 is amended but does > not declare the advice in RFC 2595 invalid, thus avoiding the entire > debate about whether separate-port or upgrade-to-TLS is better. Best > to avoid unnecessary debates when getting a spec standardized... Ok with me. > Section 3 (simplify): > > POP3S uses TLS [RFC5246] to provide protection from eavesdropping and > tampering with POP3 protocol content. The security considerations of > TLS [RFC5246] > and those related to server identity verification [RFC6125] > [I-D.melnikov-email-tls-certs] apply. Sure.
- Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls… Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls… Chris Newman
- Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls… Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls… Chris Newman
- Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls… Alexey Melnikov
- Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls… Chris Newman
- Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.… Mykyta Yevstifeyev