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

[Mykyta Yevstifeyev <evnikita2@xxxxxxxxx>]

Chris, all,

Chris agreed to co-author the document, so these are my responses from 
the "co-author's" point of view.

18.08.2011 3:39, 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.

Here I concur with Alexey that SHOULD NOT is fine to add such sentence.

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

I'm fine with such change.

> 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'm OK to remove "updates RFC 1939".  However, the current abstract, 
compared with the proposed, seems to be clearer.

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

So this change seems 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.

The analogy with HTTP, I'm convinced, is very useful; however, some of 
the improvements you propose here will be incorporated.  (Later:) I've 
left the following text:

   Two ways of protecting POP3 with TLS have been deployed (like 2 ways
   of securing HTTP [RFC2616]; see below).  The first includes
   establishing TLS layer connection during the POP3 transaction (also
   known as upgrading to TLS) [RFC2595].  The other one involves
   establishing TLS connection directly before establishing POP3
   transaction.  Unlike the former, this way (called "POP3S" throughout
   this document) has not been previously specified in an RFC.  (In the
   case with HTTP the first way is specified in RFC 2817 [RFC2817]; the
   second one - in RFC 2818 [RFC2818].)

   This document specifies POP3S.  It updates RFC 2595 [RFC2595] (see
   Section 2.5 for justification).  This memo also updates the
   registration of the TCP well-known port 995, used with 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

These changes seem fine.

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

This might be considered that POP3S is a protocol that is different from 
POP3.  However, I'll try to change this sentence so that it gets shorter 
and clearer.  I think the following is fine:

   After the client has received the +OK response to the authentication
   command, they both enter TRANSACTION state.

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

This was changed to:

   POP3S uses the default port 995.  Section 4 updates the IANA
   registration for this port.

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

You're the author of RFC 2595, so you know better :-).  So I'll change 
this text.

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

OK.

Mykyta

>         - Chris