Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
From: Mykyta Yevstifeyev <[email-masked]>
To: Chris Newman <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Date: Thu, 25 Aug 2011 12:17:24 +0300
List-Id: <ietf-pop3ext.imc.org>

24.08.2011 6:41, Chris Newman wrote:
> Only aesthetic editorial suggestions left, use if you wish...
>
> --On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev 
> <[email-masked]> wrote:
>> 18.08.2011 3:39, Chris Newman wrote:
>>
>> [ . . . ]
>>> 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.
>
> I can live with either text. But consider changing the final clause 
> to: "establishing a TLS connection directly before the POP3 
> transaction". Note that "TLS" standards for "Transport Layer 
> Security", so "Transport Layer Security layer connection" just sounds 
> wrong to me, thus the suggestion to drop the redundant "layer".

Fine; fixed now.

>
>>>   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:
>
> Ok, how about this (to make the analogy appear in one place instead of 
> a subordinate clause with a forward reference):
>
> OLD:
>     Two ways of protecting POP3 with TLS have been deployed (like 2 ways
>     of securing HTTP [RFC2616]; see below).  The first includes
> NEW suggestion:
>     Two ways of protecting POP3 with TLS have been deployed similar to 
> the
>     two specified ways of protecting HTTP [RFC2616] with TLS described in
>     RFC 2817 [RFC2817] and RFC 2818 [RFC2818]. The first includes ...

When pointing to RFCs 2817 & 2818 after brief description of what these 
two ways mean, the reader can thus apply them to these references.  So 
I'll leave the current text (and I don't think it's a significant issue 
to have much discussion and debate).

>
>> 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.
>
> How about:
>     After the client has received the +OK response to the authentication
>     command, both the client and server enter TRANSACTION state.

Fixed.

Mykyta

>
> Otherwise looks good.
>
>         - Chris
>
>
>
>

Date: Tue, 23 Aug 2011 20:41:12 -0700
From: Chris Newman <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Sender: [email-masked]

Only aesthetic editorial suggestions left, use if you wish...

--On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev <[email-masked]> 
wrote:
> 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.

That works for me.

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

I can live with either text. But consider changing the final clause to: 
"establishing a TLS connection directly before the POP3 transaction". Note 
that "TLS" standards for "Transport Layer Security", so "Transport Layer 
Security layer connection" just sounds wrong to me, thus the suggestion to 
drop the redundant "layer".

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

Ok, how about this (to make the analogy appear in one place instead of a 
subordinate clause with a forward reference):

OLD:
     Two ways of protecting POP3 with TLS have been deployed (like 2 ways
     of securing HTTP [RFC2616]; see below).  The first includes
NEW suggestion:
     Two ways of protecting POP3 with TLS have been deployed similar to the
     two specified ways of protecting HTTP [RFC2616] with TLS described in
     RFC 2817 [RFC2817] and RFC 2818 [RFC2818]. The first includes ...

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

How about:
     After the client has received the +OK response to the authentication
     command, both the client and server enter TRANSACTION state.

Otherwise looks good.

		- Chris

Date: Tue, 23 Aug 2011 08:07:33 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Chris Newman <[email-masked]>
CC: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Sender: [email-masked]

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

Date: Fri, 19 Aug 2011 11:17:09 -0700
From: Chris Newman <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Mykyta Yevstifeyev <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Sender: [email-masked]

--On August 19, 2011 12:21:14 +0100 Alexey Melnikov 
<[email-masked]> wrote:
> 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.

I'd be fine with a SHOULD NOT.

It's an important usability issue -- many clients pop up an intrusive 
"certificate selection dialog" if the server asks for a certificate. The 
NSS APIs support this check although the APIs to do so are difficult to use 
and non-obvious (you have to search for a cert with a client-certificate CA 
trust flag in the certificate db).

		- Chris

Date: Fri, 19 Aug 2011 12:21:14 +0100
From: Alexey Melnikov <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Mykyta Yevstifeyev <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Sender: [email-masked]

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.

Date: Wed, 17 Aug 2011 17:39:18 -0700
From: Chris Newman <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>, [email-masked]
Cc: Alexey Melnikov <[email-masked]>
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Sender: [email-masked]

>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

Date: Fri, 12 Aug 2011 12:29:35 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: [email-masked]
CC: Alexey Melnikov <[email-masked]>
Subject: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Sender: [email-masked]

Hello all,

Based on discussions on this list, we have uploaded the new version of 
POP-over-TLS draft:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : POP3 over TLS
> 	Author(s)       : Alexey Melnikov
>                            Mykyta Yevstifeyev
> 	Filename        : draft-melnikov-pop3-over-tls-01.txt
> 	Pages           : 7
> 	Date            : 2011-08-11
>
>     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.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-melnikov-pop3-over-tls-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-melnikov-pop3-over-tls-01.txt

The HTML-ized link is 
http://tools.ietf.org/html/draft-melnikov-pop3-over-tls-01.  Please 
provide your further comments, copied to Alexey Melnikov (just use 
'Reply all').

Thanks,
Mykyta Yevstifeyev

Date: Tue, 09 Aug 2011 17:15:01 +0200
From: Paul Smith <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Sender: [email-masked]

On 09/08/2011 06:14, Mykyta Yevstifeyev wrote:
> 09.08.2011 0:59, Chris Newman wrote:
>> --On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev 
>> <[email-masked]> wrote:
>>> Well, in the case when we define a response code, a clear reason for
>>> issuing it should be stated.  For the STATE response code, there is no
>>> one.  With respect to POP3S.  After some discussions with Alexey we
>>> reached the agreement to follow RFC 1939, and state the following: (1)
>>> TLS negotiation --> /AUTHORIZATION/ (2) [due to client/server's 
>>> settings]
>>> use SASL EXTERNAL --> (3) [if 2 fails, or there was no convention 
>>> between
>>> client and server] authenticate itself --> /TRANSACTION/ (4) actual
>>> transaction.  So the response code for this purpose isn't useful any 
>>> more.
>>
>> Ok. So then why is the WRONG-STATE code useful enough to be worth the 
>> trouble to publish a document?
>>
>> The litmus test that's been mostly followed for IMAP is that a 
>> response code is justified if the client can usefully behave 
>> differently as a result of the response code. Can you articulate how 
>> the client would usefully behave differently as a result of this 
>> code? If so, I suggest adding that explanation to the document.
>
> There already is.  When the client receives such response, it should 
> change its state according to the server's one.  If client and a 
> server are unsynchronized, WRONG-STATE response code will facilitate 
> their synchronizing.
My view is that if a POP3 agent will be changed according to a new 
document, it should be changed to use authentication - even if it's SASL 
EXTERNAL, so 'WRONG-STATE' will never happen

If we are just documenting existing behaviour, then a 'WRONG-STATE' code 
is irrelevant as that is not in existing behaviour

So, either way the 'WRONG-STATE' code is no use.

Date: Tue, 09 Aug 2011 07:14:13 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Sender: [email-masked]

09.08.2011 0:59, Chris Newman wrote:
> --On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev 
> <[email-masked]> wrote:
>> Well, in the case when we define a response code, a clear reason for
>> issuing it should be stated.  For the STATE response code, there is no
>> one.  With respect to POP3S.  After some discussions with Alexey we
>> reached the agreement to follow RFC 1939, and state the following: (1)
>> TLS negotiation --> /AUTHORIZATION/ (2) [due to client/server's 
>> settings]
>> use SASL EXTERNAL --> (3) [if 2 fails, or there was no convention 
>> between
>> client and server] authenticate itself --> /TRANSACTION/ (4) actual
>> transaction.  So the response code for this purpose isn't useful any 
>> more.
>
> Ok. So then why is the WRONG-STATE code useful enough to be worth the 
> trouble to publish a document?
>
> The litmus test that's been mostly followed for IMAP is that a 
> response code is justified if the client can usefully behave 
> differently as a result of the response code. Can you articulate how 
> the client would usefully behave differently as a result of this code? 
> If so, I suggest adding that explanation to the document.

There already is.  When the client receives such response, it should 
change its state according to the server's one.  If client and a server 
are unsynchronized, WRONG-STATE response code will facilitate their 
synchronizing.

Mykyta

>
>         - Chris
>
>

Date: Mon, 08 Aug 2011 14:59:22 -0700
From: Chris Newman <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
Cc: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Sender: [email-masked]

--On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev <[email-masked]> 
wrote:
> Well, in the case when we define a response code, a clear reason for
> issuing it should be stated.  For the STATE response code, there is no
> one.  With respect to POP3S.  After some discussions with Alexey we
> reached the agreement to follow RFC 1939, and state the following: (1)
> TLS negotiation --> /AUTHORIZATION/ (2) [due to client/server's settings]
> use SASL EXTERNAL --> (3) [if 2 fails, or there was no convention between
> client and server] authenticate itself --> /TRANSACTION/ (4) actual
> transaction.  So the response code for this purpose isn't useful any more.

Ok. So then why is the WRONG-STATE code useful enough to be worth the 
trouble to publish a document?

The litmus test that's been mostly followed for IMAP is that a response 
code is justified if the client can usefully behave differently as a result 
of the response code. Can you articulate how the client would usefully 
behave differently as a result of this code? If so, I suggest adding that 
explanation to the document.

		- Chris

Date: Sat, 06 Aug 2011 07:38:53 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Chris Newman <[email-masked]>
CC: Paul Smith <[email-masked]>, [email-masked]
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Sender: [email-masked]

05.08.2011 9:07, Chris Newman wrote:
> I see no reason for this to be experimental; it should be standards 
> track. We have deployed protocols with similar error codes (including 
> SMTP 503). It has not been harmful and has at least been helpful to 
> debugging.

Well, I'll change this.

>
> I think the specification should explicitly state that servers 
> implementing WRONG-STATE MUST also advertise and implement the 
> RESP-CODES capability from RFC 2449. That makes client parsing 
> deterministic.

This is clear from RFC 2449, but to be clearer, I'll mention this.

>
> I think it would be helpful to state that a motivation for this 
> document is to provide a way for deployed (non-standard) pop3s servers 
> that support client certificate authentication to deterministically 
> indicate whether or not the server accepted the client certificate in 
> a way that also does not break backwards compatibility with deployed 
> client software. That is a good reason for a new error code, and 
> without a statement like that, it is not obvious this idea merits the 
> cost of RFC publication. And informative reference to your pop3s 
> specification may also be helpful for that purpose.
>
> It occurs to me the response code could be more useful if it was 
> "STATE/<state>" rather than WRONG-STATE. Then it could be used in the 
> "+OK" banner after SSL/TLS negotiation in pop3s. In that case, we'd have:
>
> <SSL/TLS negotiation with client cert>
> +OK [STATE/TRANSACTION] client certificate accepted
>
> or
>
> <SSL/TLS negotation with client cert>
> +OK [STATE/AUTHORIZATION] ready for authentication
>
> That avoids the need for an upgraded client/server pair to try 
> something and see if it fails.

Well, in the case when we define a response code, a clear reason for 
issuing it should be stated.  For the STATE response code, there is no 
one.  With respect to POP3S.  After some discussions with Alexey we 
reached the agreement to follow RFC 1939, and state the following: (1) 
TLS negotiation --> /AUTHORIZATION/ (2) [due to client/server's 
settings] use SASL EXTERNAL --> (3) [if 2 fails, or there was no 
convention between client and server] authenticate itself --> 
/TRANSACTION/ (4) actual transaction.  So the response code for this 
purpose isn't useful any more.

Mykyta

>
>         - Chris
>
> --On August 4, 2011 6:57:06 +0300 Mykyta Yevstifeyev 
> <[email-masked]> wrote:
>
>>
>> Hello all,
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>     Title           : Post Office Protocol (POP) WRONG-STATE 
>>> Response Code
>>>     Author(s)       : Mykyta Yevstifeyev
>>>     Filename        : draft-yevstifeyev-pop-wrong-state-00.txt
>>>     Pages           : 4
>>>     Date            : 2011-08-03
>>>
>>>     This document defines new experimental POP response code to be used
>>>     in responses to commands which mismatch the state they were 
>>> given in.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00 
>>>
>>> .txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00. 
>>>
>>> txt
>>
>> The HTMLized version -
>> http://tools.ietf.org/html/draft-yevstifeyev-pop-wrong-state-00.  Any
>> comments are welcome, of course.
>>
>> Mykyta Yevstifeyev
>>
>>
>
>
>
>
>

Date: Thu, 04 Aug 2011 23:07:03 -0700
From: Chris Newman <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>, Paul Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Sender: [email-masked]

I see no reason for this to be experimental; it should be standards track. 
We have deployed protocols with similar error codes (including SMTP 503). 
It has not been harmful and has at least been helpful to debugging.

I think the specification should explicitly state that servers implementing 
WRONG-STATE MUST also advertise and implement the RESP-CODES capability 
from RFC 2449. That makes client parsing deterministic.

I think it would be helpful to state that a motivation for this document is 
to provide a way for deployed (non-standard) pop3s servers that support 
client certificate authentication to deterministically indicate whether or 
not the server accepted the client certificate in a way that also does not 
break backwards compatibility with deployed client software. That is a good 
reason for a new error code, and without a statement like that, it is not 
obvious this idea merits the cost of RFC publication. And informative 
reference to your pop3s specification may also be helpful for that purpose.

It occurs to me the response code could be more useful if it was 
"STATE/<state>" rather than WRONG-STATE. Then it could be used in the "+OK" 
banner after SSL/TLS negotiation in pop3s. In that case, we'd have:

<SSL/TLS negotiation with client cert>
+OK [STATE/TRANSACTION] client certificate accepted

or

<SSL/TLS negotation with client cert>
+OK [STATE/AUTHORIZATION] ready for authentication

That avoids the need for an upgraded client/server pair to try something 
and see if it fails.

		- Chris

--On August 4, 2011 6:57:06 +0300 Mykyta Yevstifeyev <[email-masked]> 
wrote:

>
> Hello all,
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> 	Title           : Post Office Protocol (POP) WRONG-STATE Response Code
>> 	Author(s)       : Mykyta Yevstifeyev
>> 	Filename        : draft-yevstifeyev-pop-wrong-state-00.txt
>> 	Pages           : 4
>> 	Date            : 2011-08-03
>>
>>     This document defines new experimental POP response code to be used
>>     in responses to commands which mismatch the state they were given in.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00
>> .txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00.
>> txt
>
> The HTMLized version -
> http://tools.ietf.org/html/draft-yevstifeyev-pop-wrong-state-00.  Any
> comments are welcome, of course.
>
> Mykyta Yevstifeyev
>
>

Date: Wed, 03 Aug 2011 16:49:29 -0400
From: Alexey Melnikov <[email-masked]>
To: Mykyta Yevstifeyev <[email-masked]>
CC: Chris Newman <[email-masked]>, [email-masked]
Subject: Re: POP handling commands given in wrong state
Sender: [email-masked]

Mykyta Yevstifeyev wrote:
> 29.07.2011 17:21, Chris Newman wrote:
>> --On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev 
>> <[email-masked]> wrote:
>>> I would really be happy if existing POP-over-TLS implementations 
>>> adhered
>>> usual POP behavior as defined in RFC 1939, and I would be happy to
>>> describe it in the corresponding document.  However, if we want to 
>>> define
>>> the current practices, we should document the technology as-is.  If we
>>> want to give POP-over-TLs a standard definition of operations, I don't
>>> really think those implementation which used the discussed POP-over-TLS
>>> algorithm will break their behavior.
>> We have a choice to define POPS-with-client-certs based on what has 
>> been deployed or define it based on how we think it should work. The 
>> latter is an architecturally cleaner choice, but is unlikely to cause 
>> the deployed implementations with the former behavior to change.
> I actually have the same opinion, but in order to suit RFC 1939 
> requirements, I think defining the mandatory use of SASL EXTERNAL 
> mechanism after TLS-authenticated POP-over-TLS session establishment 
> should resolve the issue.  Even if the server has authenticated the 
> user upon TLS negotiation, formal authentication with RFC 5034 AUTH 
> command using EXTERNAL mechanism will be obligatory to be preformed.
I strongly prefer documenting existing behaviour for POP3S (and document 
what is broken with it, if anything).
I don't think mandatory use of SASL EXTERNAL is necessarily the current 
practice. Other SASL mechanisms can be used on pop3s ports (at least in 
some server implementations).

Date: Thu, 04 Aug 2011 06:57:06 +0300
From: Mykyta Yevstifeyev <[email-masked]>
To: Paul Smith <[email-masked]>
CC: [email-masked]
Subject: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt
Sender: [email-masked]

Hello all,

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Post Office Protocol (POP) WRONG-STATE Response Code
> 	Author(s)       : Mykyta Yevstifeyev
> 	Filename        : draft-yevstifeyev-pop-wrong-state-00.txt
> 	Pages           : 4
> 	Date            : 2011-08-03
>
>     This document defines new experimental POP response code to be used
>     in responses to commands which mismatch the state they were given in.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-pop-wrong-state-00.txt

The HTMLized version - 
http://tools.ietf.org/html/draft-yevstifeyev-pop-wrong-state-00.  Any 
comments are welcome, of course.

Mykyta Yevstifeyev