Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7P9GujK045515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 02:16:56 -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 p7P9Gu7E045514; Thu, 25 Aug 2011 02:16:56 -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 mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7P9GsWV045505 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 25 Aug 2011 02:16:55 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by bkbzv15 with SMTP id zv15so2605423bkb.16 for ; Thu, 25 Aug 2011 02:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OgrkdIdtuknLBAHj5W8+EcOCUb2T7QKtQMhqYnuejJk=; b=rZ/Z5hlIVe7IpdaD6jLk50Kmu9ZJlMA+xPQ6m7Kus96rDtfgJNeGIDY4vKw06eJwCT GrTBQEOiewuo4xkGQKodo1ez/1AuB2Vu27VHdG01dNQ0fc1J2H9ZrQYOEjbPATRKFn8B Xt3B5HD5ldVu2Ezaq4qFX5YHDcPuhDyzMEMt4= Received: by 10.204.128.80 with SMTP id j16mr2888920bks.9.1314263813546; Thu, 25 Aug 2011 02:16:53 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f9sm109304bkt.3.2011.08.25.02.16.51 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 02:16:52 -0700 (PDT) Message-ID: <4E561324.30000@gmail.com> Date: Thu, 25 Aug 2011 12:17:24 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Chris Newman CC: ietf-pop3ext@imc.org, Alexey Melnikov Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> <4E533595.2020907@gmail.com> In-Reply-To: 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: List-ID: List-Unsubscribe: 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 > 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 > > > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OHevFT087429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 10:40:57 -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 p7OHevex087428; Wed, 24 Aug 2011 10:40:57 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OHetOi087401 for ; Wed, 24 Aug 2011 10:40:56 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7OHeroK010470; Wed, 24 Aug 2011 17:40:53 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7OHeqOj012734; Wed, 24 Aug 2011 17:40:52 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQG00028141TS00@gotmail.us.oracle.com>; Wed, 24 Aug 2011 10:40:52 -0700 (PDT) Date: Tue, 23 Aug 2011 20:41:12 -0700 From: Chris Newman To: Mykyta Yevstifeyev Cc: ietf-pop3ext@imc.org, Alexey Melnikov Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt Message-id: In-reply-to: <4E533595.2020907@gmail.com> References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> <4E533595.2020907@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Only aesthetic editorial suggestions left, use if you wish... --On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7N5744c091839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 22:07:04 -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 p7N574oe091838; Mon, 22 Aug 2011 22:07:04 -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 mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7N571Bd091831 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 22 Aug 2011 22:07:02 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxg17 with SMTP id 17so11011fxg.16 for ; Mon, 22 Aug 2011 22:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KpHoju7rwKaMtFFkuv9/QLTArQ2nRo60nJAUCT7pGnQ=; b=mQVFr7hPo7whJL1OdJtJU0rAuyFidVbiNL+9NBGAQvQ3+j71KdmdMqXXweSfFiQtUs uFYXQgcpBn1XgRjsXCVu5LWjpcG9nap44ekyzfhX48HTCqhpHinRTx/zwFoS4RQtDPjW iysKV5Ifhw/T4rDIDaB/4Yuxp4srnvx5xRCe4= Received: by 10.223.63.139 with SMTP id b11mr4862686fai.87.1314076021240; Mon, 22 Aug 2011 22:07:01 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 22sm714631fay.28.2011.08.22.22.06.57 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 22:06:59 -0700 (PDT) Message-ID: <4E533595.2020907@gmail.com> Date: Tue, 23 Aug 2011 08:07:33 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Chris Newman CC: ietf-pop3ext@imc.org, Alexey Melnikov 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> 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: List-ID: List-Unsubscribe: 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 > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7JIGqjJ034976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Aug 2011 11:16:52 -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 p7JIGqtv034975; Fri, 19 Aug 2011 11:16:52 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7JIGpiY034970 for ; Fri, 19 Aug 2011 11:16:51 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7JIHH8X024660; Fri, 19 Aug 2011 18:17:18 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7JIHBb6058993; Fri, 19 Aug 2011 18:17:12 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.44.76] (dhcp-rmdc-twvpn-2-vpnpool-10-159-53-10.vpn.oracle.com [10.159.53.10]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ60062HTGL1W00@gotmail.us.oracle.com>; Fri, 19 Aug 2011 11:17:11 -0700 (PDT) Date: Fri, 19 Aug 2011 11:17:09 -0700 From: Chris Newman To: Alexey Melnikov Cc: Mykyta Yevstifeyev , ietf-pop3ext@imc.org Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt Message-id: <7BEC116FEB251DB1F9B7B5CF@96B2F16665FF96BAE59E9B90> In-reply-to: <4E4E472A.8030709@isode.com> References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> <4E4E472A.8030709@isode.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On August 19, 2011 12:21:14 +0100 Alexey Melnikov 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 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 ; 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 ; 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 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 , 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: 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]. 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. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7I0d1q6027703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2011 17:39:01 -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 p7I0d1XM027702; Wed, 17 Aug 2011 17:39:01 -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 brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7I0d0rD027695 for ; Wed, 17 Aug 2011 17:39:00 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7I0dMRT014178; Thu, 18 Aug 2011 00:39:23 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7I0dMZq024458; Thu, 18 Aug 2011 00:39:22 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQ300H3QLTIC700@gotmail.us.oracle.com>; Wed, 17 Aug 2011 17:39:21 -0700 (PDT) Date: Wed, 17 Aug 2011 17:39:18 -0700 From: Chris Newman To: Mykyta Yevstifeyev , ietf-pop3ext@imc.org Cc: Alexey Melnikov Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt Message-id: <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> In-reply-to: <4E44F27F.802@gmail.com> References: <4E44F27F.802@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7C9Sde3052331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Aug 2011 02:28:39 -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 p7C9Sd0Q052330; Fri, 12 Aug 2011 02:28:39 -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 mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7C9SbQM052325 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 12 Aug 2011 02:28:39 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by bkbzv15 with SMTP id zv15so2444942bkb.16 for ; Fri, 12 Aug 2011 02:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=XluhyvkJw6X0K+nOPU0vzLfniHhibZT9bufdgLUlkno=; b=cRi5Vr8ZARIHjIrDYty54v5fp99JmFIVQ8wQYKNkIHrwSHsnkybxH717vXQe55zLdP rRfiHUQHPpuvBjr0MTLxVOBAexzKNWy7jcACYWlob4NDCgSt3z4ydM+mCp6F2vU7ySoN zY6tx4PVB34V401xRxeAuLvpIhJjiII+2ssH4= Received: by 10.204.138.137 with SMTP id a9mr247787bku.99.1313141339450; Fri, 12 Aug 2011 02:28:59 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x19sm747285bkt.42.2011.08.12.02.28.57 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 02:28:58 -0700 (PDT) Message-ID: <4E44F27F.802@gmail.com> Date: Fri, 12 Aug 2011 12:29:35 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ietf-pop3ext@imc.org CC: Alexey Melnikov Subject: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79FNhKi092272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Aug 2011 08:23:43 -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 p79FNhDA092271; Tue, 9 Aug 2011 08:23:43 -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 mail.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p79FNeHv092265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Aug 2011 08:23:42 -0700 (MST) (envelope-from prvs=0202B864E8=paul@pscs.co.uk) Received: from lmail.pscs.co.uk ([217.155.61.14]) by mail.pscs.co.uk ([46.20.224.92] running VPOP3) with ESMTP; Tue, 9 Aug 2011 16:19:50 +0100 Received: from [192.168.0.6] ([2.14.192.115]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 9 Aug 2011 16:15:05 +0100 Message-ID: <4E414EF5.8040507@pscs.co.uk> Date: Tue, 09 Aug 2011 17:15:01 +0200 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mykyta Yevstifeyev CC: Chris Newman , ietf-pop3ext@imc.org Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> <4E3CC55D.2050507@gmail.com> <4E40B415.2060307@gmail.com> In-Reply-To: <4E40B415.2060307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V4.0.0e - Registered X-Organisation: Paul Smith Computer Services Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 >> 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. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p794DIdD059556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 21:13:18 -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 p794DIBx059555; Mon, 8 Aug 2011 21:13:18 -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 mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p794DGsX059550 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 8 Aug 2011 21:13:17 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxg17 with SMTP id 17so4873752fxg.16 for ; Mon, 08 Aug 2011 21:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u4lWHlVrmcj+3aYnklmYHte5yQdyCcXmBJ90JC239II=; b=E/Ejmh7wGr30PrgStxsIbHEBPPECd3/Zy8cGVX6VLEG7mUJ5EpT/VVCiBiNp+p2he7 LjL+gZ0vqmeFTuJwl3RMkfr4TQka105o3+PlzYGt9Uf10GnGQE5o8d9skbZX4cGe+WKu by4iefG1Mr2UIMnMzl9bsOvG4mB8cBGFsBmdA= Received: by 10.223.121.204 with SMTP id i12mr8726503far.83.1312863216713; Mon, 08 Aug 2011 21:13:36 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q15sm4652505fah.8.2011.08.08.21.13.35 (version=SSLv3 cipher=OTHER); Mon, 08 Aug 2011 21:13:35 -0700 (PDT) Message-ID: <4E40B415.2060307@gmail.com> Date: Tue, 09 Aug 2011 07:14:13 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Chris Newman CC: Paul Smith , ietf-pop3ext@imc.org Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> <4E3CC55D.2050507@gmail.com> In-Reply-To: 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: List-ID: List-Unsubscribe: 09.08.2011 0:59, Chris Newman wrote: > --On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev > 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 > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p78Lx80n047598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 14:59:08 -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 p78Lx8UJ047597; Mon, 8 Aug 2011 14:59:08 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p78Lx74k047592 for ; Mon, 8 Aug 2011 14:59:08 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p78LxO1u011285; Mon, 8 Aug 2011 21:59:25 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p78LxO9b046070; Mon, 8 Aug 2011 21:59:24 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LPM00735QEYNH00@gotmail.us.oracle.com>; Mon, 08 Aug 2011 14:59:24 -0700 (PDT) Date: Mon, 08 Aug 2011 14:59:22 -0700 From: Chris Newman To: Mykyta Yevstifeyev Cc: Paul Smith , ietf-pop3ext@imc.org Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt Message-id: In-reply-to: <4E3CC55D.2050507@gmail.com> References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> <4E3CC55D.2050507@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p764c0PC010616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 21:38:00 -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 p764c07V010615; Fri, 5 Aug 2011 21:38:00 -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 mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p764bvSY010608 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 5 Aug 2011 21:37:58 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxg17 with SMTP id 17so817188fxg.16 for ; Fri, 05 Aug 2011 21:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AG4QTXkuqX+ZZMBU9hERf1hy7DrORC7JCrQNj7yWZeQ=; b=JhJAEkPkeRF+keEv4qfyJpvFRObskBUdyMCKtiNO0tdP53ZLqq/G/qsT8n1Qy+QEfw BcR5Z0Zeyrjh4BPcOczyso1ZqLUF80fnzQGTG1+zJsgDHnUmIQw3vGtUzagPEx3kMPw1 gfem6y5bbmcBp4i8oxBtiEuqTb9OtU5Yg/4lQ= Received: by 10.223.50.131 with SMTP id z3mr3961688faf.127.1312605496026; Fri, 05 Aug 2011 21:38:16 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x13sm2419022fah.29.2011.08.05.21.38.14 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 21:38:15 -0700 (PDT) Message-ID: <4E3CC55D.2050507@gmail.com> Date: Sat, 06 Aug 2011 07:38:53 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Chris Newman CC: Paul Smith , ietf-pop3ext@imc.org Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> In-Reply-To: <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> 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: List-ID: List-Unsubscribe: 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/" 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: > > > +OK [STATE/TRANSACTION] client certificate accepted > > or > > > +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 > 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 >> >> > > > > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p75IfG3i090712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 11:41:16 -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 p75IfGOh090711; Fri, 5 Aug 2011 11:41:16 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p75IfEgO090706 for ; Fri, 5 Aug 2011 11:41:15 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p75IfWmr002968; Fri, 5 Aug 2011 18:41:32 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail2-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p75IfUGW018511; Fri, 5 Aug 2011 18:41:30 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LPG00G2JX93YO00@gotmail.us.oracle.com>; Fri, 05 Aug 2011 11:41:29 -0700 (PDT) Date: Thu, 04 Aug 2011 23:07:03 -0700 From: Chris Newman To: Mykyta Yevstifeyev , Paul Smith Cc: ietf-pop3ext@imc.org Subject: Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt Message-id: <648FDC3E662E2D6F71B314B0@96B2F16665FF96BAE59E9B90> In-reply-to: <4E3A1892.7030301@gmail.com> References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E3A1892.7030301@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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/" 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: +OK [STATE/TRANSACTION] client certificate accepted or +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 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 > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p74F1BEl027822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Aug 2011 08:01:11 -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 p74F1BoM027821; Thu, 4 Aug 2011 08:01:11 -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 p74F198K027816 for ; Thu, 4 Aug 2011 08:01:10 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [188.29.26.188] (188.29.26.188.threembb.co.uk [188.29.26.188]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 4 Aug 2011 16:01:26 +0100 Message-ID: <4E39B459.9050102@isode.com> Date: Wed, 03 Aug 2011 16:49:29 -0400 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Mykyta Yevstifeyev CC: Chris Newman , ietf-pop3ext@imc.org Subject: Re: POP handling commands given in wrong state References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> <4E2E8E10.9070209@pscs.co.uk> <4E2EBEC5.1000306@gmail.com> <4E2EC1E0.7010504@pscs.co.uk> <4E2F9AA7.80901@gmail.com> <4E2FD131.3020406@pscs.co.uk> <4E323154.8050802@gmail.com> <83B7234709A6F65D7EC783FE@96B2F16665FF96BAE59E9B90> <4E33D102.7030503@gmail.com> In-Reply-To: <4E33D102.7030503@gmail.com> 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: List-ID: List-Unsubscribe: Mykyta Yevstifeyev wrote: > 29.07.2011 17:21, Chris Newman wrote: >> --On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev >> 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). Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p743uCAe099799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2011 20:56:12 -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 p743uCdw099798; Wed, 3 Aug 2011 20:56:12 -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 mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p743u9hA099793 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 3 Aug 2011 20:56:11 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxg17 with SMTP id 17so2687731fxg.16 for ; Wed, 03 Aug 2011 20:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=R4M9BLHKX7+qWpftqfVb3c/uMaSYtEeP6njKNHhDYr8=; b=ohHuYvtyEGcbgIJe+tVw3Ptc/m/3ljDJLAYAq3niNhjABGY+ItgH8LywD5K1AvqrTM BJTP53VrT79UYR3rnRlFl020pbG+HPLBBhqLV7Y1dIYPIGRfXPJKxGFu86fXPmvFRPQ6 Lj3Z7J7JgB6vdI61J0+M0P1QOO4102ApWhtjI= Received: by 10.223.75.13 with SMTP id w13mr438713faj.115.1312430188165; Wed, 03 Aug 2011 20:56:28 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id a2sm947243fak.25.2011.08.03.20.56.26 (version=SSLv3 cipher=OTHER); Wed, 03 Aug 2011 20:56:27 -0700 (PDT) Message-ID: <4E3A1892.7030301@gmail.com> Date: Thu, 04 Aug 2011 06:57:06 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Smith CC: ietf-pop3ext@imc.org Subject: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> In-Reply-To: <4E2E7708.3080004@pscs.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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