Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Alexey Melnikov <> Fri, 19 August 2011 11:20 UTC

Received: from (localhost []) by (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
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p7JBKxlL017770; Fri, 19 Aug 2011 04:20:59 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p7JBKvcF017764 for <>; Fri, 19 Aug 2011 04:20:58 -0700 (MST) (envelope-from
Received: from [] ( []) by (submission channel) via TCP with ESMTPA id <>; Fri, 19 Aug 2011 12:21:23 +0100
Message-ID: <>
Date: Fri, 19 Aug 2011 12:21:14 +0100
From: Alexey Melnikov <>
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 <>
CC: Mykyta Yevstifeyev <>,
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
References: <> <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
Precedence: bulk
List-Archive: <>
List-ID: <>
List-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].


>   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


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


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