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

[Chris Newman <[e-mail]>]

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

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.


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.

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.

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

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.

		- Chris