Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6U9bKiU029933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jul 2011 02:37:20 -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 p6U9bKXO029932; Sat, 30 Jul 2011 02:37:20 -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 p6U9bHnh029926 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sat, 30 Jul 2011 02:37:18 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxg17 with SMTP id 17so4882370fxg.16 for ; Sat, 30 Jul 2011 02:37:33 -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=S4WbYoJNOev15kIyN0UAsujsNIZeCf6NxE1RQETQewE=; b=qVRhBlF3FMAitiQCSeGPGOr3Li5lHTxD8o2jUArNtlMCwQ1Em2T6/uZbKHZEHid4uI o6Zmzy3ts6NQ9803HTJaKCl2RnBHmMBCZOQOFnk2cKKkdjLB6R9yOSwYtgtGjaV7xGYp eeqQ1S9ndLuuJEMzZGo5ilCVqtxhw7DDPsJC8= Received: by 10.223.160.75 with SMTP id m11mr3232734fax.42.1312018651671; Sat, 30 Jul 2011 02:37:31 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id y15sm1555548fah.35.2011.07.30.02.37.29 (version=SSLv3 cipher=OTHER); Sat, 30 Jul 2011 02:37:30 -0700 (PDT) Message-ID: <4E33D102.7030503@gmail.com> Date: Sat, 30 Jul 2011 12:38:10 +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, Alexey Melnikov 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> In-Reply-To: <83B7234709A6F65D7EC783FE@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: 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. > >> The "discouragement" of RFC 2595 actually has no considerable reasons. > > I disagree. I happen to support documenting POPS because I believe > people will continue to use it as they do today regardless of what > anyone thinks should be done, and I'd like our documents to give > accurate guidance for interoperability as long as it's possible and > what's deployed is not egregiously broken. I consider POP+STLS a > superior architecture that is cleaner are more interoperable and > consider it preferable to pops in almost all cases. I believe section > 7 of RFC 2595 remains largely correct today, but accept those > arguments are not sufficiently compelling to prevent deployment of > pops, so I'd prefer to document pops for interoperability reasons > despite its flawed architecture. I also agree that STLS is a bit better that currently deployed POP-over-TLS, so we both concur here. > >> Those reasons mentioned in Section 7 of RFC 2595 concern that (1) ports >> are limited resource, (2) new URI scheme needed, (3) there might be >> confusion of users, (4) choose "to use or not to use POP-over-TLS" is >> worse than "use TLS when possible, and negotiate it with STLS". >> Regarding these points, I should say: (1) isn't a problem now; moreover, >> 995 port number is already assigned, > > IPv4 address space is not a problem right now, either. But that does > not mean it will never be a problem and it's OK to unnecessarily waste > that resource. But port 995 is registered and won't go away, so I > grant that part of your point. Well, RFC-to-be-6335 discourages use of separate port for "secure" versions of protocols, encouraging use of such technologies as STLS in POP or Upgrade: TLS in HTTP; so does it for service names. However, as 995 port number was assigned long before yet-unpublished RFC 6335 even was planned, this is just the matter of history. > >> (2) new URI scheme isn't a problem, too; http/https schemes illustrate > this as well, > > I disagree. Are you sure in all cases when you need to use http: and > when you need to use https:? Do you ever enter sensitive data into a > web page when "http:" is in the address bar? Are you sure that's safe? > If you're an ISP would you prefer to give your users just an email > address and password (RFC 6186), an email address and pop server (POP > + STLS) or an email address and pop URL (pop, pops). I'd say the > latter is the least desirable of these choices as it will result in > the most transcription errors and support calls. The new URI scheme is hypothetical only; the existing 'pop' URI scheme isn't meant to be widely-deployed as well, (as the author of RFC 2384 claimed). Should there be such need, though, the new URI scheme will be very easy to define. (Actually, the initial idea which led to defining POP-over-TLS was 'pops' URI scheme - http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme.) > >> (3) currently, the users >> don't usually set use of POP-over-TLS due to their willing, but rather >> because this is how the user agent should be configured to match the >> server, as server's administration points the user to do, and > > It intrudes into the UI forcing end-users to make choices related to > security they may not understand. That problem can be worked around > with an extra level of complexity such as that provided by RFC 6186, > but it is still an architectural design error. > >> (4) is eliminated when the server (server's administration) clearly > states that >> POP-over-TLS should or should not be used. POP-over-TLS isn't worse >> that >> STLS. > > I am not convinced. The correct model is for clients to be > secure-by-default without the need for any statement from server > administration or any configuration by client users. That is, the > first time I run a mail client against a new server it will > "permanently latch on" SSL/TLS for that account if it is available (in > the event SSL/TLS is not available, the client should confirm with the > user that an insecure connection to that server is acceptable). This > can be done via RFC 6186 for servers that offer both POP and POPS and > can also be done for POP-with-STLS. It's faster and easier to code in > the latter case. Secure-by-default is an ideal variant; but I don't think most of existing user agents have such behavior. Nor do the servers; many of them allow to specify whether secure POP should be used. Moreover, RFC 6186 was published very recently, in March 2011, and currently I don't see it has already gained widespread deployment. 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 p6U3xGqd021677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2011 20:59:17 -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 p6U3xGuo021676; Fri, 29 Jul 2011 20:59: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 sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6U3xFQh021671 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 29 Jul 2011 20:59:15 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from brmsunmail2-sfbay.uk.sun.com ([10.79.11.101]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id p6U3xLjD014412; Sat, 30 Jul 2011 03:59:28 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 p6U3xK4H055159; Sat, 30 Jul 2011 03:59:20 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.50.151] (dhcp-rmdc-twvpn-2-vpnpool-10-159-50-151.vpn.oracle.com [10.159.50.151]) by gotmail.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LP400F04OESJB00@gotmail.us.oracle.com>; Fri, 29 Jul 2011 20:59:19 -0700 (PDT) Date: Fri, 29 Jul 2011 10:21:28 -0400 From: Chris Newman To: Mykyta Yevstifeyev , Paul Smith Cc: ietf-pop3ext@imc.org, Alexey Melnikov Subject: Re: POP handling commands given in wrong state Message-id: <83B7234709A6F65D7EC783FE@96B2F16665FF96BAE59E9B90> In-reply-to: <4E323154.8050802@gmail.com> 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> 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 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. > The "discouragement" of RFC 2595 actually has no considerable reasons. I disagree. I happen to support documenting POPS because I believe people will continue to use it as they do today regardless of what anyone thinks should be done, and I'd like our documents to give accurate guidance for interoperability as long as it's possible and what's deployed is not egregiously broken. I consider POP+STLS a superior architecture that is cleaner are more interoperable and consider it preferable to pops in almost all cases. I believe section 7 of RFC 2595 remains largely correct today, but accept those arguments are not sufficiently compelling to prevent deployment of pops, so I'd prefer to document pops for interoperability reasons despite its flawed architecture. > Those reasons mentioned in Section 7 of RFC 2595 concern that (1) ports > are limited resource, (2) new URI scheme needed, (3) there might be > confusion of users, (4) choose "to use or not to use POP-over-TLS" is > worse than "use TLS when possible, and negotiate it with STLS". > Regarding these points, I should say: (1) isn't a problem now; moreover, > 995 port number is already assigned, IPv4 address space is not a problem right now, either. But that does not mean it will never be a problem and it's OK to unnecessarily waste that resource. But port 995 is registered and won't go away, so I grant that part of your point. > (2) new URI scheme isn't a problem, too; http/https schemes illustrate this as well, I disagree. Are you sure in all cases when you need to use http: and when you need to use https:? Do you ever enter sensitive data into a web page when "http:" is in the address bar? Are you sure that's safe? If you're an ISP would you prefer to give your users just an email address and password (RFC 6186), an email address and pop server (POP + STLS) or an email address and pop URL (pop, pops). I'd say the latter is the least desirable of these choices as it will result in the most transcription errors and support calls. > (3) currently, the users > don't usually set use of POP-over-TLS due to their willing, but rather > because this is how the user agent should be configured to match the > server, as server's administration points the user to do, and It intrudes into the UI forcing end-users to make choices related to security they may not understand. That problem can be worked around with an extra level of complexity such as that provided by RFC 6186, but it is still an architectural design error. > (4) is eliminated when the server (server's administration) clearly states that > POP-over-TLS should or should not be used. POP-over-TLS isn't worse that > STLS. I am not convinced. The correct model is for clients to be secure-by-default without the need for any statement from server administration or any configuration by client users. That is, the first time I run a mail client against a new server it will "permanently latch on" SSL/TLS for that account if it is available (in the event SSL/TLS is not available, the client should confirm with the user that an insecure connection to that server is acceptable). This can be done via RFC 6186 for servers that offer both POP and POPS and can also be done for POP-with-STLS. It's faster and easier to code in the latter case. - Chris Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6T43ijg066362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2011 21:03:45 -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 p6T43isK066361; Thu, 28 Jul 2011 21:03:44 -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 p6T43gYM066356 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 28 Jul 2011 21:03:43 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxg17 with SMTP id 17so2969002fxg.16 for ; Thu, 28 Jul 2011 21:03:58 -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=IbFaIy2Mu7Wb36iHpCLwC+8MeNEJFCXir5CewtaS4tY=; b=xYRAmDlroiXdnqlSkUK355Qk7lCkLoV0c7hpgXnv6uu+M5q/peOwRMnpD7e9MH5OAU CwxtzdVCEQfgxXR+LfDspe43NngLlihVWUKPe0pzXOsJ2qgzMV31UycO7bTWC2kqiv4k JK2tWaCljDdx7D3FetwHpAlAU3gHdjiQdJYQs= Received: by 10.223.120.134 with SMTP id d6mr1063876far.112.1311912238069; Thu, 28 Jul 2011 21:03:58 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w11sm840983faj.14.2011.07.28.21.03.55 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 21:03:56 -0700 (PDT) Message-ID: <4E323154.8050802@gmail.com> Date: Fri, 29 Jul 2011 07:04:36 +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, Alexey Melnikov 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> In-Reply-To: <4E2FD131.3020406@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: Paul, 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. The "discouragement" of RFC 2595 actually has no considerable reasons. Those reasons mentioned in Section 7 of RFC 2595 concern that (1) ports are limited resource, (2) new URI scheme needed, (3) there might be confusion of users, (4) choose "to use or not to use POP-over-TLS" is worse than "use TLS when possible, and negotiate it with STLS". Regarding these points, I should say: (1) isn't a problem now; moreover, 995 port number is already assigned, (2) new URI scheme isn't a problem, too; http/https schemes illustrate this as well, (3) currently, the users don't usually set use of POP-over-TLS due to their willing, but rather because this is how the user agent should be configured to match the server, as server's administration points the user to do, and (4) is eliminated when the server (server's administration) clearly states that POP-over-TLS should or should not be used. POP-over-TLS isn't worse that STLS. Regarding how POP-over-TLS session is set up. The first variant is simple, and has no concerns. I mean (1) TCP connection --> (2) TLS negotiation --> (3) USER-PASS/AUTH authentication -> (4) POP transaction. This adheres the usual RFC 1939 definition and seems not to have any problems. The second variant is the most fishy. I mean (1) TCP connection --> (2) TLS negotiation, which stands for POP authorization --> (3a) USER-PASS/AUTH authentication, if (2) fails/ (3b) or, alternatively, use SASL EXTERNAL mechnism --> (4) POP transaction. This algorithm violates RFC 1939, but it is a willful violation, if we don't consider (3b). Replacing some of required POP steps with TLS steps may be considered to lead to a new protocol. Regarding the SASL EXTERNAL mechanism, I actually think it's appropriate to be used use, but the question - whether servers will also begin to use it? Mykyta 27.07.2011 11:49, Paul Smith wrote: > On 27/07/2011 05:57, Mykyta Yevstifeyev wrote: >>> Hmm, I think if you are talking about existing implementations using >>> a deprecated system, then trying to alter the behaviour of them is >>> unlikely to achieve anything... >> I wouldn't say it is deprecated; POP-over-TLS is used even more often >> that STLS, as I've already mentioned. We're trying to give it the >> official documentation and set the standard behavior of the >> server/client. > > It is 'discouraged' then. Also, because, as of now, there is no > standards track document saying how POP3-over-TLS should work, I think > you can safely call it non-standard. Non-standard + 'discouraged' + a > better standardised option = seems to suggest that no one should be > starting to use that system now... There is no good reason to use > POP3-over-TLS instead of STLS, so I think it needs to be made clear > that POP3-over-TLS is second-best compared to STLS (as someone who's > implemented both, I found STLS a lot easier than POP3-over-TLS to > implement). > > If you are trying to specify what future servers who want to use this > 'discouraged' system should do, then simply say they must start up in > the authorization stage after the TLS session has been started (just > as with STLS). Anything else is too far from the POP3 standard, and as > Randall said 'magic'. > > I am not aware of any 'well known' POP3 clients which will skip the > authorization stage, so any server which requires this must just be > used for 'internal' use, and thus not really relevant for standards. > Internal use servers can do anything they want so these aren't doing > 'POP3-over-TLS', they're doing 'almost-POP3-over-TLS' which is fine > for internal use. > > The only reason to do a POP3-over-TLS implementation nowadays should > be to allow compatibility with some popular old software which doesn't > support STLS. AFAIK, that is essentially old versions of > Outlook/Outlook Express - those use USER/PASS after connecting over TLS. > > I strongly feel that the POP3 session should start in the > authorization stage, as understood by everyone who uses a standardised > POP3 service (ie one where the developer has read RFC 1939). So, > USER/AUTH/APOP is needed as one of the first commands after connecting. > > As Randall suggested, use SASL EXTERNAL if you want (isn't this the > whole point of SASL EXTERNAL?), but you should need an AUTH. What's > the problem with needing that? > >> In our case the AUTHORIZATION is safely replaced by TLS negotiation. >> It also happens directly after TCP connection, but skipping the >> greeting, which is replaced by TLS ServerHello message. > Which is breaking the POP3 standard, because the greeting is specified > as a 'one line [text] greeting' > >>> If you are just wanting to document existing behaviour, then this >>> doesn't matter, as neither the extended response nor standard >>> compliant behaviour is possible. >> But if we try to unify all existing behavior, this will be great, >> won't it? > > Well, what would be great IMHO would be to destroy all POP3-over-TLS > implementations... They should never have been done in the first place! > > But, failing that, it's fairly obvious the 'most correct' > implementation is to do it as Gmail, Thunderbird, etc, etc have done, > and have it as normal RFC 1939 but with a TLS 'wrapper' around the > session. > > The 'broken' implementation of not needing AUTH after session > establishment is the one that needs to be fixed somehow. Either you > kludge it by having some mechanism that the client needs to understand > for the server to say 'I'm in the wrong state now', or you fix it > properly by having the server enter AUTHORIZATION state. > > > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6R8pATC055982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2011 01:51: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 p6R8pAO1055981; Wed, 27 Jul 2011 01:51:10 -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 p6R8p7ut055975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Jul 2011 01:51:09 -0700 (MST) (envelope-from prvs=0189A3A045=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; Wed, 27 Jul 2011 09:49:56 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Wed, 27 Jul 2011 09:49:53 +0100 Message-ID: <4E2FD131.3020406@pscs.co.uk> Date: Wed, 27 Jul 2011 09:49:53 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev CC: ietf-pop3ext@imc.org, Alexey Melnikov 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> In-Reply-To: <4E2F9AA7.80901@gmail.com> Content-Type: text/plain; charset=UTF-8; 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 27/07/2011 05:57, Mykyta Yevstifeyev wrote: >> Hmm, I think if you are talking about existing implementations using >> a deprecated system, then trying to alter the behaviour of them is >> unlikely to achieve anything... > I wouldn't say it is deprecated; POP-over-TLS is used even more often > that STLS, as I've already mentioned. We're trying to give it the > official documentation and set the standard behavior of the server/client. It is 'discouraged' then. Also, because, as of now, there is no standards track document saying how POP3-over-TLS should work, I think you can safely call it non-standard. Non-standard + 'discouraged' + a better standardised option = seems to suggest that no one should be starting to use that system now... There is no good reason to use POP3-over-TLS instead of STLS, so I think it needs to be made clear that POP3-over-TLS is second-best compared to STLS (as someone who's implemented both, I found STLS a lot easier than POP3-over-TLS to implement). If you are trying to specify what future servers who want to use this 'discouraged' system should do, then simply say they must start up in the authorization stage after the TLS session has been started (just as with STLS). Anything else is too far from the POP3 standard, and as Randall said 'magic'. I am not aware of any 'well known' POP3 clients which will skip the authorization stage, so any server which requires this must just be used for 'internal' use, and thus not really relevant for standards. Internal use servers can do anything they want so these aren't doing 'POP3-over-TLS', they're doing 'almost-POP3-over-TLS' which is fine for internal use. The only reason to do a POP3-over-TLS implementation nowadays should be to allow compatibility with some popular old software which doesn't support STLS. AFAIK, that is essentially old versions of Outlook/Outlook Express - those use USER/PASS after connecting over TLS. I strongly feel that the POP3 session should start in the authorization stage, as understood by everyone who uses a standardised POP3 service (ie one where the developer has read RFC 1939). So, USER/AUTH/APOP is needed as one of the first commands after connecting. As Randall suggested, use SASL EXTERNAL if you want (isn't this the whole point of SASL EXTERNAL?), but you should need an AUTH. What's the problem with needing that? > In our case the AUTHORIZATION is safely replaced by TLS negotiation. > It also happens directly after TCP connection, but skipping the > greeting, which is replaced by TLS ServerHello message. Which is breaking the POP3 standard, because the greeting is specified as a 'one line [text] greeting' >> If you are just wanting to document existing behaviour, then this >> doesn't matter, as neither the extended response nor standard >> compliant behaviour is possible. > But if we try to unify all existing behavior, this will be great, > won't it? Well, what would be great IMHO would be to destroy all POP3-over-TLS implementations... They should never have been done in the first place! But, failing that, it's fairly obvious the 'most correct' implementation is to do it as Gmail, Thunderbird, etc, etc have done, and have it as normal RFC 1939 but with a TLS 'wrapper' around the session. The 'broken' implementation of not needing AUTH after session establishment is the one that needs to be fixed somehow. Either you kludge it by having some mechanism that the client needs to understand for the server to say 'I'm in the wrong state now', or you fix it properly by having the server enter AUTHORIZATION state. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6R54Q5u046235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 22:04:26 -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 p6R54PhI046234; Tue, 26 Jul 2011 22:04:25 -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-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6R54Oah046229 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 26 Jul 2011 22:04:25 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by eya28 with SMTP id 28so1890789eya.21 for ; Tue, 26 Jul 2011 22:04:39 -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=3mbBOIrNda0gSNOjWUg8+HKFvMN3KI7mIpMh8Kf85n4=; b=MEGYbBOv9X4/e4/Sf4behXAZPQ4z/sl63QABlmix2Ul3t8bk6xB80Yz9EAAqMznOsW A/8ThO1WHFRWheRY+O6IMHmnY1N6IqH9rCWDS3XUZT9UxJwfHTuAXwhRA30nZiyYzmIH fK9QdL81OzpB/zD0Rb2Ls+YaND0yAobMwEa90= Received: by 10.204.18.203 with SMTP id x11mr307560bka.294.1311743079258; Tue, 26 Jul 2011 22:04:39 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o11sm245720bkt.4.2011.07.26.22.04.36 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 22:04:38 -0700 (PDT) Message-ID: <4E2F9C8E.8040403@gmail.com> Date: Wed, 27 Jul 2011 08:05:18 +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: Randall Gellens CC: Paul Smith , ietf-pop3ext@imc.org, Alexey Melnikov Subject: Re: POP handling commands given in wrong state References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@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: 26.07.2011 17:35, Randall Gellens wrote: > At 6:17 AM -0700 7/26/11, Randall Gellens wrote: > >> Per RFC 3206, the server should issue the AUTH-RESP-CODE capability >> tag, indicating "that the server includes the AUTH response code with >> any authentication error caused by a problem with the user's >> credentials" and then in the case you cite, don't issue the AUTH >> response code in an -ERR response to USER. >> >> By issuing the AUTH response code and then not including the AUTH >> response code, that indicates that the error has nothing to do with >> the user's credentials. > > Just to be clear, if the server issued AUTH-RESP-CODE, then the result > to USER can be interpreted: > +OK: Accepted, proceed to PASS > -ERR [AUTH]: Failed, problem with user credentials (not > likely with USER anyway) > -ERR [SYS/TEMP]: Failed due to temporary system problem, try > again later > -ERR [SYS/PERM]: Failed due to permanent system problem, advise > user to call for help > -ERR: No problem w/ credentials nor system, if you > used TLS w/ cert, maybe authenticated already This is an interesting idea. We can also define the new code, AUTH-YET, to answer USER/PASS/AUTH given when already authenticated: -ERR [AUTH-YET]: Already authenticated -ERR: Other error. The initially proposed WRONG-STATE can be a generalization of the aforementioned AUTH-YET, eg. C: STAT S: -ERR [WRONG-STATE/AUTHORIZATION] Not authenticated yet; current state is AUTHORIZATION --- C: C: USER foo S: -ERR [WRONG-STATE/TRANSACTION] Already in TRANSACTION. --- etc. Mykyta > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6R4uOOQ046031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 21:56:24 -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 p6R4uOlo046030; Tue, 26 Jul 2011 21:56:24 -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-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6R4uLv7046025 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 26 Jul 2011 21:56:22 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by ewy20 with SMTP id 20so1694374ewy.16 for ; Tue, 26 Jul 2011 21:56: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; bh=sqXCVGL8RQEP6PrvfSTL6CTJaP14qqMaMj4G+PUpqy8=; b=wW9senCeCO+2cv9SoYgdCQ1bZ70BdsSLaZ3+FYCtNYwAcrmU66Leujsv/ztiI7PELU 8HJ0iI0B0zz08e34BlVTH9A6npZnBHPicX9Ear5vuutJKDsq4hu5rlDBFMDGXW+yl+Nd 2S/gGiO+HzAyjV00puhpL6LhHWuU9wSewte50= Received: by 10.204.122.210 with SMTP id m18mr311066bkr.138.1311742596113; Tue, 26 Jul 2011 21:56:36 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id x19sm240537bkt.42.2011.07.26.21.56.30 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 21:56:35 -0700 (PDT) Message-ID: <4E2F9AA7.80901@gmail.com> Date: Wed, 27 Jul 2011 07:57:11 +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, Alexey Melnikov 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> In-Reply-To: <4E2EC1E0.7010504@pscs.co.uk> Content-Type: multipart/alternative; boundary="------------030708020903000000070100" Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030708020903000000070100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 26.07.2011 16:32, Paul Smith wrote: > On 26/07/2011 14:19, Mykyta Yevstifeyev wrote: >>> Going straight from session establishment into transaction state >>> seems wrong to me, given the base POP3 spec which POP3-over-TLS is >>> building on. >> The matter is that many POP servers support authentication using >> X.509 certificate which was supplied during TLS negotiation and do >> not require further authentication. In such case issuing USER will >> lead to -ERR, as the server is already in TRANSACTION then. Other >> servers implement POP-over-TLS so that further authentication is also >> required (eg. Gmail, which I personally am using). >> >>> >>> >>> BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete >>> - isn't the 'STLS' command (RFC 2595) the way we should be doing >>> things now? I thought the POP3S way was deprecated. >>> >>> Note that the RFC 2595 says: >>> "The STLS command is only permitted in AUTHORIZATION state and the >>> server remains in AUTHORIZATION state, even if client credentials >>> are supplied during the TLS negotiation." so with STLS you have to >>> authenticate (not sure why it's called 'authorization' state when >>> it's really 'authentication' state, but that's not relevant) even if >>> the TLS has already supplied the user details. >> Yes, RFC 2595 discouraged use of POP-over-TLS. However, it is now >> used even wider than STLS, which led to effort to document this >> mode. See above for note on why authorization might not be necessary >> after TLS negotiation. > > Hmm, I think if you are talking about existing implementations using a > deprecated system, then trying to alter the behaviour of them is > unlikely to achieve anything... I wouldn't say it is deprecated; POP-over-TLS is used even more often that STLS, as I've already mentioned. We're trying to give it the official documentation and set the standard behavior of the server/client. > > Personally, I'd say that a POP3 server that skips the authorization > state because of the certificate is not standards compliant, because > there is no standard which allows that behaviour. > > RFC 1939 section 3 says "Once the TCP connection has been opened and > the POP3 server has sent the greeting, the session enters the > AUTHORIZATION state. In this state, the client must identify itself to > the POP3 server." In our case the AUTHORIZATION is safely replaced by TLS negotiation. It also happens directly after TCP connection, but skipping the greeting, which is replaced by TLS ServerHello message. > > Potentially, the client could identify itself using the certificate - > HOWEVER, this has to happen *after the POP3 server has sent the > greeting* for it to be standards compliant, so it can't be done using > the certificate with POP3-over-TLS (it could have been, using the STLS > extension, except that specifically excludes that option) This assumes use of STLS, which performs TLS negotiation during POP3 session. POP-over-TLS deliberately makes use of TLS before POP session. > > So, any server which does not enter AUTHORIZATION state after the > connection has been opened and the POP3 server has sent the greeting > is NOT RFC 1939 compliant. See above. Server greeting = ServerHello TLS message; authentication = TLS negotiation. > > If you are wanting to change the behaviour of existing POP3-over-TLS > server implementations so they send a POP3 extended response, then you > should rather change their behaviour so they are compliant to the > existing RFC 1939 instead... They can't be anyway as some required steps of RFC 1939 are replaced by TLS steps. This results in a modified protocol. > > If you are just wanting to document existing behaviour, then this > doesn't matter, as neither the extended response nor standard > compliant behaviour is possible. But if we try to unify all existing behavior, this will be great, won't it? Mykyta Yevstifeyev > > IMHO > > > --------------030708020903000000070100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 26.07.2011 16:32, Paul Smith wrote:
On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
Going straight from session establishment into transaction state seems wrong to me, given the base POP3 spec which POP3-over-TLS is building on.
The matter is that many POP servers support authentication using X.509 certificate which was supplied during TLS negotiation and do not require further authentication.  In such case issuing USER will lead to -ERR, as the server is already in TRANSACTION then.  Other servers implement POP-over-TLS so that further authentication is also required (eg. Gmail, which I personally am using).



BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - isn't the 'STLS' command (RFC 2595) the way we should be doing things now? I thought the POP3S way was deprecated.

Note that the RFC 2595 says:
"The STLS command is only permitted in AUTHORIZATION state and the server remains in AUTHORIZATION state, even if client credentials are supplied during the TLS negotiation." so with STLS you have to authenticate (not sure why it's called 'authorization' state when it's really 'authentication' state, but that's not relevant) even if the TLS has already supplied the user details.
Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now used even wider than STLS, which led to effort to document this mode.  See above for note on why authorization might not be necessary after TLS negotiation.

Hmm, I think if you are talking about existing implementations using a deprecated system, then trying to alter the behaviour of them is unlikely to achieve anything...
I wouldn't say it is deprecated; POP-over-TLS is used even more often that STLS, as I've already mentioned.  We're trying to give it the official documentation and set the standard behavior of the server/client.

Personally, I'd say that a POP3 server that skips the authorization state because of the certificate is not standards compliant, because there is no standard which allows that behaviour.

RFC 1939 section 3 says "Once the TCP connection has been opened and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In this state, the client must identify itself to the POP3 server."
In our case the AUTHORIZATION is safely replaced by TLS negotiation.  It also happens directly after TCP connection, but skipping the greeting, which is replaced by TLS ServerHello message.

Potentially, the client could identify itself using the certificate - HOWEVER, this has to happen *after the POP3 server has sent the greeting* for it to be standards compliant, so it can't be done using the certificate with POP3-over-TLS (it could have been, using the STLS extension, except that specifically excludes that option)
This assumes use of STLS, which performs TLS negotiation during POP3 session.  POP-over-TLS deliberately makes use of TLS before POP session.

So, any server which does not enter AUTHORIZATION state after the connection has been opened and the POP3 server has sent the greeting is NOT RFC 1939 compliant.
See above.  Server greeting = ServerHello TLS message; authentication = TLS negotiation.

If you are wanting to change the behaviour of existing POP3-over-TLS server implementations so they send a POP3 extended response, then you should rather change their behaviour so they are compliant to the existing RFC 1939 instead...
They can't be anyway as some required steps of RFC 1939 are replaced by TLS steps.  This results in a modified protocol.

If you are just wanting to document existing behaviour, then this doesn't matter, as neither the extended response nor standard compliant behaviour is possible.
But if we try to unify all existing behavior, this will be great, won't it?

Mykyta Yevstifeyev

IMHO




--------------030708020903000000070100-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QIcxnl019832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 11:38: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 p6QIcxDT019831; Tue, 26 Jul 2011 11:38: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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QIcwLw019826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jul 2011 11:38:58 -0700 (MST) (envelope-from randy@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1311705554; x=1343241554; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<4E2EBEC5.1000306@gmail.com>|References: =20<4E2E49AC.9090207@gmail.com>=20<4E2E7708.3080004@pscs. co.uk>=0D=0A=20<4E2E8762.5030805@gmail.com>=20<4E2E8E10.9 070209@pscs.co.uk>=0D=0A=20<4E2EBEC5.1000306@gmail.com> |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Tue,=202 6=20Jul=202011=2011:36:29=20-0700|To:=20Mykyta=20Yevstife yev=20,=20Paul=20Smith=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20POP=20handling=20commands=20given=20in =20wrong=20state|CC:=20 |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.39.5]; bh=gespxe5MJ8vdqVPXJNQP+WW2eNhSFnm6VGoxrUNCQhM=; b=LKJgjT2TLXdJ/uPM4hEuwjYD0D3OTipEVAI37OVkeyrnqRwABhXbVLe8 0Q4JcsNtzdv6GP4zeMTj1kq+hNebAZ5Bnuwv09win2uC6FyyqnMlWBwbo q2DuGT0O9Tt7KAYhJMuybUonoMAomVGCuWoNfm3uwZCEo4oJTn47bnliG 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6419"; a="106044791" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 26 Jul 2011 11:39:13 -0700 X-IronPort-AV: E=Sophos;i="4.67,269,1309762800"; d="scan'208";a="100341058" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 11:39:13 -0700 Received: from [130.129.83.90] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 26 Jul 2011 11:39:12 -0700 Message-ID: In-Reply-To: <4E2EBEC5.1000306@gmail.com> References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> <4E2E8E10.9070209@pscs.co.uk> <4E2EBEC5.1000306@gmail.com> X-Mailer: Eudora for Mac OS X Date: Tue, 26 Jul 2011 11:36:29 -0700 To: Mykyta Yevstifeyev , Paul Smith From: Randall Gellens Subject: Re: POP handling commands given in wrong state CC: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 4:19 PM +0300 7/26/11, Mykyta Yevstifeyev wrote: > The matter is that many POP servers support authentication using > X.509 certificate which was supplied during TLS negotiation and do > not require further authentication. In such case issuing USER will > lead to -ERR, as the server is already in TRANSACTION then. Could you use AUTH with SASL EXTERNAL for this case? Seems a little cleaner. Otherwise it's magic that you don't need AUTH/USER > Other servers implement POP-over-TLS so that further > authentication is also required (eg. Gmail, which I personally am > using). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QEjmqR007520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 07:45:48 -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 p6QEjm8j007519; Tue, 26 Jul 2011 07:45:48 -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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QEjl0n007514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jul 2011 07:45:48 -0700 (MST) (envelope-from randy@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1311691563; x=1343227563; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20 |References:=20<4E2E49AC.9090207@gmail.com>=20<4E2E7708.3 080004@pscs.co.uk>=0D=0A=20<4E2E8762.5030805@gmail.com> =20|X-Mailer:=20Eu dora=20for=20Mac=20OS=20X|Date:=20Tue,=2026=20Jul=202011 =2007:35:42=20-0700|To:=20Mykyta=20Yevstifeyev=20,=20Paul=20Smith=20|From: =20Randall=20Gellens=20|Subject:=20Re :=20POP=20handling=20commands=20given=20in=20wrong=20stat e|CC:=20,=20Alexey=20Melnikov=20|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.39.5]; bh=/u7VZp1tOPObbYiKYW8yK5WdEvk6yQHQ1sAh8g+IWBk=; b=tKIKoP0YGU9gpSKiMd+zteBEW8eLV6ss+XmmAfme1xVddNwK6/EJF7dF gmpaj+6JF14I9qGzX+NvghWw0AV3GPnV+GSNB4IBwmaLNiHOcig9fsbwC nJla2Wnunfazt49X+OO44B6QPU5yvlaMGKLeXtXwCASXvo9gH4PabJbGG Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6418"; a="105987155" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 26 Jul 2011 07:46:02 -0700 X-IronPort-AV: E=Sophos;i="4.67,269,1309762800"; d="scan'208";a="100139140" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 07:46:02 -0700 Received: from [130.129.83.90] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 26 Jul 2011 07:46:01 -0700 Message-ID: In-Reply-To: References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> X-Mailer: Eudora for Mac OS X Date: Tue, 26 Jul 2011 07:35:42 -0700 To: Mykyta Yevstifeyev , Paul Smith From: Randall Gellens Subject: Re: POP handling commands given in wrong state CC: , Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:17 AM -0700 7/26/11, Randall Gellens wrote: > Per RFC 3206, the server should issue the AUTH-RESP-CODE capability > tag, indicating "that the server includes the AUTH response code > with any authentication error caused by a problem with the user's > credentials" and then in the case you cite, don't issue the AUTH > response code in an -ERR response to USER. > > By issuing the AUTH response code and then not including the AUTH > response code, that indicates that the error has nothing to do with > the user's credentials. Just to be clear, if the server issued AUTH-RESP-CODE, then the result to USER can be interpreted: +OK: Accepted, proceed to PASS -ERR [AUTH]: Failed, problem with user credentials (not likely with USER anyway) -ERR [SYS/TEMP]: Failed due to temporary system problem, try again later -ERR [SYS/PERM]: Failed due to permanent system problem, advise user to call for help -ERR: No problem w/ credentials nor system, if you used TLS w/ cert, maybe authenticated already -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Too often, we see a failure to distinguish sufficiently clearly between the intrinsic problems of computer science and the difficulties resulting from the shortcomings of our various educational systems. --Edsger W. Dijkstra Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QEUT94006852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 07:30:29 -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 p6QEUT6I006851; Tue, 26 Jul 2011 07:30:29 -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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QEURIl006845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jul 2011 07:30:28 -0700 (MST) (envelope-from randy@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1311690643; x=1343226643; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<4E2EC28A.3020301@pscs.co.uk>|References: =20<4E2E49AC.9090207@gmail.com>=20<4E2E7708.3080004@pscs. co.uk>=0D=0A=20<4E2E8762.5030805@gmail.com>=20=0D=0A=20<4E2EC28A.3020301@ps cs.co.uk>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date: =20Tue,=2026=20Jul=202011=2007:30:15=20-0700|To:=20Paul =20Smith=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20POP=20handling=20co mmands=20given=20in=20wrong=20state|CC:=20Mykyta=20Yevsti feyev=20,=20, =20Alexey=0D=0A=20Melnikov=20 |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.39.5]; bh=oaM/C9AYBZ+sekHr5SZQZ4AgWydZwj+rRMLYL6uG1Gc=; b=EQsZ1xuYAhBl8M+lFf8h9zHtJ24n0rRRzD6iXhhXEUruqDF9oYCdBJ0N RaVcNSzuFI4iQH0UhbliWqN8YH6BWHDugdCZOWEoazjmb6FXdNNgluLiC PlWBVFtA5RGo5IRMmx7RCsEImetrW0zSrOWInYw5e0Xvh5FfkWYxa+79y M=; X-IronPort-AV: E=McAfee;i="5400,1158,6418"; a="105983040" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 26 Jul 2011 07:30:20 -0700 X-IronPort-AV: E=Sophos;i="4.67,269,1309762800"; d="scan'208";a="53570300" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 07:30:20 -0700 Received: from [130.129.83.90] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 26 Jul 2011 07:30:19 -0700 Message-ID: In-Reply-To: <4E2EC28A.3020301@pscs.co.uk> References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> <4E2EC28A.3020301@pscs.co.uk> X-Mailer: Eudora for Mac OS X Date: Tue, 26 Jul 2011 07:30:15 -0700 To: Paul Smith From: Randall Gellens Subject: Re: POP handling commands given in wrong state CC: Mykyta Yevstifeyev , , Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 2:35 PM +0100 7/26/11, Paul Smith wrote: > On 26/07/2011 14:17, Randall Gellens wrote: > >> >> Per RFC 4206, the server should issue the AUTH-RESP-CODE >> capability tag, indicating "that the server includes the AUTH >> response code with any authentication error caused by a problem >> with the user's credentials" and then in the case you cite, don't >> issue the AUTH response code in an -ERR response to USER. >> > > Hmm - maybe you have the wrong RFC number there - or I'm missing > something in our implementation because our mail server doesn't do > anything about "Label Switched Paths (LSP) Hierarchy with > Generalized Multi-Protocol Label Switching (GMPLS) Traffic > Engineering (TE)"... :) Sorry about that, slip of the fingers. It's RFC 3206 (not 4206). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- See, in my line of work, you got to keep repeating things over and over and over again for the truth to sink in, to kind of catapult the propaganda. --U.S. President George W. Bush in New York, May 24, 2005 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDj1s8003612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 06:45: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 p6QDj1hS003611; Tue, 26 Jul 2011 06:45: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 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 p6QDiv0V003593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 06:44:58 -0700 (MST) (envelope-from prvs=018878D732=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, 26 Jul 2011 14:39:56 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 26 Jul 2011 14:35:06 +0100 Message-ID: <4E2EC28A.3020301@pscs.co.uk> Date: Tue, 26 Jul 2011 14:35:06 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Randall Gellens CC: Mykyta Yevstifeyev , ietf-pop3ext@imc.org, Alexey Melnikov Subject: Re: POP handling commands given in wrong state References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010602000702070802040002" 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: This is a multi-part message in MIME format. --------------010602000702070802040002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 26/07/2011 14:17, Randall Gellens wrote: > > Per RFC 4206, the server should issue the AUTH-RESP-CODE capability > tag, indicating "that the server includes the AUTH response code with > any authentication error caused by a problem with the user's > credentials" and then in the case you cite, don't issue the AUTH > response code in an -ERR response to USER. Hmm - maybe you have the wrong RFC number there - or I'm missing something in our implementation because our mail server doesn't do anything about "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"... :) --------------010602000702070802040002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 26/07/2011 14:17, Randall Gellens wrote:

Per RFC 4206, the server should issue the AUTH-RESP-CODE capability tag, indicating "that the server includes the AUTH response code with any authentication error caused by a problem with the user's credentials" and then in the case you cite, don't issue the AUTH response code in an -ERR response to USER.

Hmm - maybe you have the wrong RFC number there - or I'm missing something in our implementation because our mail server doesn't do anything about "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)"... :)



--------------010602000702070802040002-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDj0Xk003605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 06:45: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 p6QDj0Fx003604; Tue, 26 Jul 2011 06:45: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.pscs.co.uk (mail.pscs.co.uk [46.20.224.92]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDivU8003594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 06:44:58 -0700 (MST) (envelope-from prvs=018878D732=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, 26 Jul 2011 14:39:57 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 26 Jul 2011 14:32:17 +0100 Message-ID: <4E2EC1E0.7010504@pscs.co.uk> Date: Tue, 26 Jul 2011 14:32:16 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev CC: 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> In-Reply-To: <4E2EBEC5.1000306@gmail.com> Content-Type: multipart/alternative; boundary="------------050608030700090309090108" 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: This is a multi-part message in MIME format. --------------050608030700090309090108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 26/07/2011 14:19, Mykyta Yevstifeyev wrote: >> Going straight from session establishment into transaction state >> seems wrong to me, given the base POP3 spec which POP3-over-TLS is >> building on. > The matter is that many POP servers support authentication using X.509 > certificate which was supplied during TLS negotiation and do not > require further authentication. In such case issuing USER will lead > to -ERR, as the server is already in TRANSACTION then. Other servers > implement POP-over-TLS so that further authentication is also required > (eg. Gmail, which I personally am using). > >> >> >> BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete >> - isn't the 'STLS' command (RFC 2595) the way we should be doing >> things now? I thought the POP3S way was deprecated. >> >> Note that the RFC 2595 says: >> "The STLS command is only permitted in AUTHORIZATION state and the >> server remains in AUTHORIZATION state, even if client credentials are >> supplied during the TLS negotiation." so with STLS you have to >> authenticate (not sure why it's called 'authorization' state when >> it's really 'authentication' state, but that's not relevant) even if >> the TLS has already supplied the user details. > Yes, RFC 2595 discouraged use of POP-over-TLS. However, it is now > used even wider than STLS, which led to effort to document this mode. > See above for note on why authorization might not be necessary after > TLS negotiation. Hmm, I think if you are talking about existing implementations using a deprecated system, then trying to alter the behaviour of them is unlikely to achieve anything... Personally, I'd say that a POP3 server that skips the authorization state because of the certificate is not standards compliant, because there is no standard which allows that behaviour. RFC 1939 section 3 says "Once the TCP connection has been opened and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In this state, the client must identify itself to the POP3 server." Potentially, the client could identify itself using the certificate - HOWEVER, this has to happen *after the POP3 server has sent the greeting* for it to be standards compliant, so it can't be done using the certificate with POP3-over-TLS (it could have been, using the STLS extension, except that specifically excludes that option) So, any server which does not enter AUTHORIZATION state after the connection has been opened and the POP3 server has sent the greeting is NOT RFC 1939 compliant. If you are wanting to change the behaviour of existing POP3-over-TLS server implementations so they send a POP3 extended response, then you should rather change their behaviour so they are compliant to the existing RFC 1939 instead... If you are just wanting to document existing behaviour, then this doesn't matter, as neither the extended response nor standard compliant behaviour is possible. IMHO --------------050608030700090309090108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26/07/2011 14:19, Mykyta Yevstifeyev wrote:
Going straight from session establishment into transaction state seems wrong to me, given the base POP3 spec which POP3-over-TLS is building on.
The matter is that many POP servers support authentication using X.509 certificate which was supplied during TLS negotiation and do not require further authentication.  In such case issuing USER will lead to -ERR, as the server is already in TRANSACTION then.  Other servers implement POP-over-TLS so that further authentication is also required (eg. Gmail, which I personally am using).



BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - isn't the 'STLS' command (RFC 2595) the way we should be doing things now? I thought the POP3S way was deprecated.

Note that the RFC 2595 says:
"The STLS command is only permitted in AUTHORIZATION state and the server remains in AUTHORIZATION state, even if client credentials are supplied during the TLS negotiation." so with STLS you have to authenticate (not sure why it's called 'authorization' state when it's really 'authentication' state, but that's not relevant) even if the TLS has already supplied the user details.
Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now used even wider than STLS, which led to effort to document this mode.  See above for note on why authorization might not be necessary after TLS negotiation.

Hmm, I think if you are talking about existing implementations using a deprecated system, then trying to alter the behaviour of them is unlikely to achieve anything...

Personally, I'd say that a POP3 server that skips the authorization state because of the certificate is not standards compliant, because there is no standard which allows that behaviour.

RFC 1939 section 3 says "Once the TCP connection has been opened and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In this state, the client must identify itself to the POP3 server."

Potentially, the client could identify itself using the certificate - HOWEVER, this has to happen *after the POP3 server has sent the greeting* for it to be standards compliant, so it can't be done using the certificate with POP3-over-TLS (it could have been, using the STLS extension, except that specifically excludes that option)

So, any server which does not enter AUTHORIZATION state after the connection has been opened and the POP3 server has sent the greeting is NOT RFC 1939 compliant.

If you are wanting to change the behaviour of existing POP3-over-TLS server implementations so they send a POP3 extended response, then you should rather change their behaviour so they are compliant to the existing RFC 1939 instead...

If you are just wanting to document existing behaviour, then this doesn't matter, as neither the extended response nor standard compliant behaviour is possible.

IMHO



--------------050608030700090309090108-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDKtQK002204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 06:20: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 p6QDKt6K002203; Tue, 26 Jul 2011 06:20:55 -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 wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDKs4s002198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Jul 2011 06:20:54 -0700 (MST) (envelope-from randy@qualcomm.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1311686470; x=1343222470; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<4E2E8762.5030805@gmail.com>|References: =20<4E2E49AC.9090207@gmail.com>=20<4E2E7708.3080004@pscs. co.uk>=0D=0A=20<4E2E8762.5030805@gmail.com>|X-Mailer:=20E udora=20for=20Mac=20OS=20X|Date:=20Tue,=2026=20Jul=202011 =2006:17:24=20-0700|To:=20Mykyta=20Yevstifeyev=20,=20Paul=20Smith=20|From: =20Randall=20Gellens=20|Subject:=20Re :=20POP=20handling=20commands=20given=20in=20wrong=20stat e|CC:=20,=20Alexey=20Melnikov=20|MIME-Version:=201.0 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii"=3B =20format=3Dflowed|X-Random-Sig-Tag:=201.0b28 |X-Originating-IP:=20[172.30.39.5]; bh=Yl0FZjYeaM38dbUwZeRqG9f85NWHwhQqCt/+9JhNtl8=; b=DdmRMl0H6ZDv2XUPgpyWv0c6dXz+VA53Ml8tbImc2VPL/kcbq5Q/S+wv qtdpQFljWMsdJ++j4t6f3vvl01HC6YRGs0G9/gxNbRNaw/bl9YRdzUUmu KjjhLBRixT8hX2txuNvQAdIEywwLkCn5idWekq9z+JLL9J4Yj8kdk9Mme 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6418"; a="105962769" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 26 Jul 2011 06:21:09 -0700 X-IronPort-AV: E=Sophos;i="4.67,266,1309762800"; d="scan'208";a="118417072" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jul 2011 06:21:08 -0700 Received: from [130.129.83.90] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 26 Jul 2011 06:21:08 -0700 Message-ID: In-Reply-To: <4E2E8762.5030805@gmail.com> References: <4E2E49AC.9090207@gmail.com> <4E2E7708.3080004@pscs.co.uk> <4E2E8762.5030805@gmail.com> X-Mailer: Eudora for Mac OS X Date: Tue, 26 Jul 2011 06:17:24 -0700 To: Mykyta Yevstifeyev , Paul Smith From: Randall Gellens Subject: Re: POP handling commands given in wrong state CC: , Alexey Melnikov MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:22 PM +0300 7/26/11, Mykyta Yevstifeyev wrote: > I meant just the situation like this. Eg., when one is using > POP3-over-TLS whereas TLS connection is established before POP > transaction starts, TLS negotiation may be used instead USER-PASS > or AUTH authentication, entering the server into the TRANSACTION > state; on the other hand, the server may require authentication > under TLS layer, entering AUTHORIZATION state after establishing > TLS connection. I and Alexey Melnikov are currently working on the > POP-over-TLS specification > (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) > and the problem is that the client don't know what state is the > server in after TLS negotiation. If the client tries giving USER > and received -ERR, it may mean that the user name is unknown or > that the user is authenticated already, and the client can't know > for sure what does it mean. Don't you have other idea of > indicating the state? Per RFC 4206, the server should issue the AUTH-RESP-CODE capability tag, indicating "that the server includes the AUTH response code with any authentication error caused by a problem with the user's credentials" and then in the case you cite, don't issue the AUTH response code in an -ERR response to USER. By issuing the AUTH response code and then not including the AUTH response code, that indicates that the error has nothing to do with the user's credentials. I agree that you would have to infer that the user is already authenticated, which isn't as nice as having an explicit response code. I'm not sure if it's worth adding the explicit tag or not, but don't have an objection to it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Think twice before speaking, but don't say "think think click click". Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDICpi001539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 06:18: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 p6QDICa0001538; Tue, 26 Jul 2011 06:18: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-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6QDI95A001532 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 26 Jul 2011 06:18:10 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by ewy20 with SMTP id 20so621297ewy.16 for ; Tue, 26 Jul 2011 06:18:23 -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; bh=yzKZ4k65m2hTWa7qhtveRyRjOLaKyJ2spivJAz7Bunw=; b=hcMrdRGqRkkDBAMjWhQ3FEJ3AqmuUQVrF8P+bUwJ+jpWMNvfbu8BKl9hPogTxtiJHd VCNgI5z3KQjYdOOa9ch3xypK8ynKLvBXOSx+paFQjg5BaDe6YQdGJ0B+E3+k28Oho858 p2IkxZFVYN9zBpyz7QkKjnNpuB4QW5WYZabN8= Received: by 10.204.148.90 with SMTP id o26mr1733091bkv.263.1311686302469; Tue, 26 Jul 2011 06:18:22 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id j20sm27885bks.23.2011.07.26.06.18.20 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 06:18:21 -0700 (PDT) Message-ID: <4E2EBEC5.1000306@gmail.com> Date: Tue, 26 Jul 2011 16:19:01 +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: 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> In-Reply-To: <4E2E8E10.9070209@pscs.co.uk> Content-Type: multipart/alternative; boundary="------------040709010300010303090803" Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------040709010300010303090803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 26.07.2011 12:51, Paul Smith wrote: > On 26/07/2011 10:22, Mykyta Yevstifeyev wrote: >> 26.07.2011 11:12, Paul Smith wrote: >>> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote: >>> >>> [ . . .] >>> >>> If the state was server defined, so that it may change on the >>> server's decision, rather than by purely bad coding in the client, >>> then yes, an extended response code may be useful, but when it is >>> only bad coding in the client which can make it happen - no. >> Paul, >> >> [Adding Alexey Melnikov to CC list; see below.] >> >> I meant just the situation like this. Eg., when one is using >> POP3-over-TLS whereas TLS connection is established before POP >> transaction starts, TLS negotiation may be used instead USER-PASS or >> AUTH authentication, entering the server into the TRANSACTION state; >> on the other hand, the server may require authentication under TLS >> layer, entering AUTHORIZATION state after establishing TLS >> connection. I and Alexey Melnikov are currently working on the >> POP-over-TLS specification >> (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and >> the problem is that the client don't know what state is the server in >> after TLS negotiation. If the client tries giving USER and received >> -ERR, it may mean that the user name is unknown or that the user is >> authenticated already, and the client can't know for sure what does >> it mean. Don't you have other idea of indicating the state? > > Hmm. I'd say that was a problem with the POP3 over TLS idea > > It seems wrong to have to try to do something, and see if you get an > error to see what you should do next. I know ESMTP does it, and the > POP3 'CAPA' do it, but that's because those things were added as a > hindsight after the base spec had been deployed. For a new standard to > need it just feels wrong. > > Personally, I'd expect authentication to always be required, even if > it's redundant. It just seems too much of a change from the base POP3 > spec to skip the authorization stage. > > So, you could have the TLS session established which establishes the > user's identity, and then do > USER anything > +OK > PASS anything > +OK > > or you could use the USER/PASS as a part of two factor authentication > (the certificate is something you have, the username/password is > something you know) > > Going straight from session establishment into transaction state seems > wrong to me, given the base POP3 spec which POP3-over-TLS is building on. The matter is that many POP servers support authentication using X.509 certificate which was supplied during TLS negotiation and do not require further authentication. In such case issuing USER will lead to -ERR, as the server is already in TRANSACTION then. Other servers implement POP-over-TLS so that further authentication is also required (eg. Gmail, which I personally am using). > > > BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - > isn't the 'STLS' command (RFC 2595) the way we should be doing things > now? I thought the POP3S way was deprecated. > > Note that the RFC 2595 says: > "The STLS command is only permitted in AUTHORIZATION state and the > server remains in AUTHORIZATION state, even if client credentials are > supplied during the TLS negotiation." so with STLS you have to > authenticate (not sure why it's called 'authorization' state when it's > really 'authentication' state, but that's not relevant) even if the > TLS has already supplied the user details. Yes, RFC 2595 discouraged use of POP-over-TLS. However, it is now used even wider than STLS, which led to effort to document this mode. See above for note on why authorization might not be necessary after TLS negotiation. Mykyta > > > --------------040709010300010303090803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 26.07.2011 12:51, Paul Smith wrote:
On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
26.07.2011 11:12, Paul Smith wrote:
On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:

[ . .  .]

If the state was server defined, so that it may change on the server's decision, rather than by purely bad coding in the client, then yes, an extended response code may be useful, but when it is only bad coding in the client which can make it happen - no.
Paul,

[Adding Alexey Melnikov to CC list; see below.]

I meant just the situation like this.  Eg., when one is using POP3-over-TLS whereas TLS connection is established before POP transaction starts, TLS negotiation may be used instead USER-PASS or AUTH authentication, entering the server into the TRANSACTION state; on the other hand, the server may require authentication under TLS layer, entering AUTHORIZATION state after establishing TLS connection.  I and Alexey Melnikov are currently working on the POP-over-TLS specification (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and the problem is that the client don't know what state is the server in after TLS negotiation.  If the client tries giving USER and received -ERR, it may mean that the user name is unknown or that the user is authenticated already, and the client can't know for sure what does it mean.  Don't you have other idea of indicating the state?

Hmm. I'd say that was a problem with the POP3 over TLS idea

It seems wrong to have to try to do something, and see if you get an error to see what you should do next. I know ESMTP does it, and the POP3 'CAPA' do it, but that's because those things were added as a hindsight after the base spec had been deployed. For a new standard to need it just feels wrong.

Personally, I'd expect authentication to always be required, even if it's redundant. It just seems too much of a change from the base POP3 spec to skip the authorization stage.

So, you could have the TLS session established which establishes the user's identity, and then do
USER anything
+OK
PASS anything
+OK

or you could use the USER/PASS as a part of two factor authentication (the certificate is something you have, the username/password is something you know)

Going straight from session establishment into transaction state seems wrong to me, given the base POP3 spec which POP3-over-TLS is building on.
The matter is that many POP servers support authentication using X.509 certificate which was supplied during TLS negotiation and do not require further authentication.  In such case issuing USER will lead to -ERR, as the server is already in TRANSACTION then.  Other servers implement POP-over-TLS so that further authentication is also required (eg. Gmail, which I personally am using).


BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - isn't the 'STLS' command (RFC 2595) the way we should be doing things now? I thought the POP3S way was deprecated.

Note that the RFC 2595 says:
"The STLS command is only permitted in AUTHORIZATION state and the server remains in AUTHORIZATION state, even if client credentials are supplied during the TLS negotiation." so with STLS you have to authenticate (not sure why it's called 'authorization' state when it's really 'authentication' state, but that's not relevant) even if the TLS has already supplied the user details.
Yes, RFC 2595 discouraged use of POP-over-TLS.  However, it is now used even wider than STLS, which led to effort to document this mode.  See above for note on why authorization might not be necessary after TLS negotiation.

Mykyta




--------------040709010300010303090803-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q9xtIn090664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 02:59:55 -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 p6Q9xtnV090663; Tue, 26 Jul 2011 02:59:55 -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 p6Q9xqUc090658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 02:59:54 -0700 (MST) (envelope-from prvs=018878D732=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, 26 Jul 2011 10:59:56 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 26 Jul 2011 10:51:12 +0100 Message-ID: <4E2E8E10.9070209@pscs.co.uk> Date: Tue, 26 Jul 2011 10:51:12 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev , 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> In-Reply-To: <4E2E8762.5030805@gmail.com> Content-Type: multipart/alternative; boundary="------------010506080401080605030006" 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: This is a multi-part message in MIME format. --------------010506080401080605030006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 26/07/2011 10:22, Mykyta Yevstifeyev wrote: > 26.07.2011 11:12, Paul Smith wrote: >> On 26/07/2011 05:59, Mykyta Yevstifeyev wrote: >> >> [ . . .] >> >> If the state was server defined, so that it may change on the >> server's decision, rather than by purely bad coding in the client, >> then yes, an extended response code may be useful, but when it is >> only bad coding in the client which can make it happen - no. > Paul, > > [Adding Alexey Melnikov to CC list; see below.] > > I meant just the situation like this. Eg., when one is using > POP3-over-TLS whereas TLS connection is established before POP > transaction starts, TLS negotiation may be used instead USER-PASS or > AUTH authentication, entering the server into the TRANSACTION state; > on the other hand, the server may require authentication under TLS > layer, entering AUTHORIZATION state after establishing TLS > connection. I and Alexey Melnikov are currently working on the > POP-over-TLS specification > (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and > the problem is that the client don't know what state is the server in > after TLS negotiation. If the client tries giving USER and received > -ERR, it may mean that the user name is unknown or that the user is > authenticated already, and the client can't know for sure what does it > mean. Don't you have other idea of indicating the state? Hmm. I'd say that was a problem with the POP3 over TLS idea It seems wrong to have to try to do something, and see if you get an error to see what you should do next. I know ESMTP does it, and the POP3 'CAPA' do it, but that's because those things were added as a hindsight after the base spec had been deployed. For a new standard to need it just feels wrong. Personally, I'd expect authentication to always be required, even if it's redundant. It just seems too much of a change from the base POP3 spec to skip the authorization stage. So, you could have the TLS session established which establishes the user's identity, and then do USER anything +OK PASS anything +OK or you could use the USER/PASS as a part of two factor authentication (the certificate is something you have, the username/password is something you know) Going straight from session establishment into transaction state seems wrong to me, given the base POP3 spec which POP3-over-TLS is building on. BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - isn't the 'STLS' command (RFC 2595) the way we should be doing things now? I thought the POP3S way was deprecated. Note that the RFC 2595 says: "The STLS command is only permitted in AUTHORIZATION state and the server remains in AUTHORIZATION state, even if client credentials are supplied during the TLS negotiation." so with STLS you have to authenticate (not sure why it's called 'authorization' state when it's really 'authentication' state, but that's not relevant) even if the TLS has already supplied the user details. --------------010506080401080605030006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26/07/2011 10:22, Mykyta Yevstifeyev wrote:
26.07.2011 11:12, Paul Smith wrote:
On 26/07/2011 05:59, Mykyta Yevstifeyev wrote:

[ . .  .]

If the state was server defined, so that it may change on the server's decision, rather than by purely bad coding in the client, then yes, an extended response code may be useful, but when it is only bad coding in the client which can make it happen - no.
Paul,

[Adding Alexey Melnikov to CC list; see below.]

I meant just the situation like this.  Eg., when one is using POP3-over-TLS whereas TLS connection is established before POP transaction starts, TLS negotiation may be used instead USER-PASS or AUTH authentication, entering the server into the TRANSACTION state; on the other hand, the server may require authentication under TLS layer, entering AUTHORIZATION state after establishing TLS connection.  I and Alexey Melnikov are currently working on the POP-over-TLS specification (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and the problem is that the client don't know what state is the server in after TLS negotiation.  If the client tries giving USER and received -ERR, it may mean that the user name is unknown or that the user is authenticated already, and the client can't know for sure what does it mean.  Don't you have other idea of indicating the state?

Hmm. I'd say that was a problem with the POP3 over TLS idea

It seems wrong to have to try to do something, and see if you get an error to see what you should do next. I know ESMTP does it, and the POP3 'CAPA' do it, but that's because those things were added as a hindsight after the base spec had been deployed. For a new standard to need it just feels wrong.

Personally, I'd expect authentication to always be required, even if it's redundant. It just seems too much of a change from the base POP3 spec to skip the authorization stage.

So, you could have the TLS session established which establishes the user's identity, and then do
USER anything
+OK
PASS anything
+OK

or you could use the USER/PASS as a part of two factor authentication (the certificate is something you have, the username/password is something you know)

Going straight from session establishment into transaction state seems wrong to me, given the base POP3 spec which POP3-over-TLS is building on.


BTW - why are you looking at POP3-over-TLS? Isn't this idea obsolete - isn't the 'STLS' command (RFC 2595) the way we should be doing things now? I thought the POP3S way was deprecated.

Note that the RFC 2595 says:
"The STLS command is only permitted in AUTHORIZATION state and the server remains in AUTHORIZATION state, even if client credentials are supplied during the TLS negotiation." so with STLS you have to authenticate (not sure why it's called 'authorization' state when it's really 'authentication' state, but that's not relevant) even if the TLS has already supplied the user details.



--------------010506080401080605030006-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q9LvYw089409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 02:21: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 p6Q9Lvuo089408; Tue, 26 Jul 2011 02:21: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 mail-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q9LsVK089394 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 26 Jul 2011 02:21:56 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by ewy20 with SMTP id 20so338718ewy.16 for ; Tue, 26 Jul 2011 02:22:09 -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=9EAGb9xLgkizLPiOtEAgxb+GANUYj8zhgcbogpRp1ik=; b=ZfegCEvfCn5/BHnUy4ySvtsZ1IfyZ91Ai12R2BSgNsdqE6C7ynOVipVoT9FwySU1cU EP3gmZtAszYdc3hOFl8dmj4o51p3U5jt30CeflY0/+TQPLS7BwGi1PArCgued5yodnYg yhl7preAlvVv/0Hnxh6arAkLnRySzy60SGMYo= Received: by 10.205.82.197 with SMTP id ad5mr1569565bkc.238.1311672129334; Tue, 26 Jul 2011 02:22:09 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id p16sm106326bku.31.2011.07.26.02.22.01 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 02:22:02 -0700 (PDT) Message-ID: <4E2E8762.5030805@gmail.com> Date: Tue, 26 Jul 2011 12:22:42 +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, Alexey Melnikov Subject: Re: POP handling commands given in wrong state 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: 26.07.2011 11:12, Paul Smith wrote: > On 26/07/2011 05:59, Mykyta Yevstifeyev wrote: > > [ . . .] > > If the state was server defined, so that it may change on the server's > decision, rather than by purely bad coding in the client, then yes, an > extended response code may be useful, but when it is only bad coding > in the client which can make it happen - no. Paul, [Adding Alexey Melnikov to CC list; see below.] I meant just the situation like this. Eg., when one is using POP3-over-TLS whereas TLS connection is established before POP transaction starts, TLS negotiation may be used instead USER-PASS or AUTH authentication, entering the server into the TRANSACTION state; on the other hand, the server may require authentication under TLS layer, entering AUTHORIZATION state after establishing TLS connection. I and Alexey Melnikov are currently working on the POP-over-TLS specification (https://datatracker.ietf.org/doc/draft-melnikov-pop3-over-tls/) and the problem is that the client don't know what state is the server in after TLS negotiation. If the client tries giving USER and received -ERR, it may mean that the user name is unknown or that the user is authenticated already, and the client can't know for sure what does it mean. Don't you have other idea of indicating the state? The user agent may allow the user to choose the authentication way for POP-over-TLS transaction. Eg., Thunderbird allows me to set POP-over-TLS and then one of the following: (1) plain auth. under TLS, (2) use AUTH command, (3) use Kerberos, or (4) use TLS certificate. I suppose if (4) is chosen, -ERR indicates that TLS certificate didn't lead to successful authentication and server is in AUTHORIZATION and +OK means that server is in TRANSACTION. (1), (2) and (3) assume that the server enters the TRANSACTION state after TLS negotiation and requires additional authentication. I don't know the situation with Outlook and/or something else, but I suppose it will be rather the same and this issue may be successfully resolved. So what's your opinion, Alexey? (Comments from 3rd parties are welcome as well, of course.) Mykyta > Just my 2p worth Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q8JvVx086685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 01:19: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 p6Q8Jvak086684; Tue, 26 Jul 2011 01:19: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 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 p6Q8JsRq086677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jul 2011 01:19:57 -0700 (MST) (envelope-from prvs=018878D732=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, 26 Jul 2011 09:19:56 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Tue, 26 Jul 2011 09:12:56 +0100 Message-ID: <4E2E7708.3080004@pscs.co.uk> Date: Tue, 26 Jul 2011 09:12:56 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mykyta Yevstifeyev , ietf-pop3ext@imc.org Subject: Re: POP handling commands given in wrong state References: <4E2E49AC.9090207@gmail.com> In-Reply-To: <4E2E49AC.9090207@gmail.com> Content-Type: text/plain; charset=UTF-8; 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 26/07/2011 05:59, Mykyta Yevstifeyev wrote: > > Hello, > > Post Office Protocol (POP) currently has no means of explicit > indicating that the command is given in the wrong state. > >> A server MUST respond to a command issued when the >> session is in an incorrect state by responding with a negative >> status >> indicator. > > doesn't give enough information to the client. The -ERR response > indicating wrong state may override -ERR response given with its > natural meaning. I propose to define the new POP extension response > code (RFC 2449), WRONG-STATE, to indicate this. Eg.: > >> C: >> S: +OK server ready >> C: STAT >> S: -ERR [WRONG-STATE] Not in TRANSACTION state yet > > Any thoughts? I wouldn't have thought it would matter AIUI the extension response codes are so that the client can understand it enough to tell the user what the error means (eg mailbox in use, rather than invalid password, during the login phase, so don't bother asking for the correct password) Client code should never issue commands in the wrong state by the time it has been released to users... It may happen during development or testing, but at that time the interested people should have enough technical ability to read the standard and realise what has happened... For that use: -ERR not in transaction state yet is just as good as -ERR [WRONG-STATE] not in transaction state yet If the state was server defined, so that it may change on the server's decision, rather than by purely bad coding in the client, then yes, an extended response code may be useful, but when it is only bad coding in the client which can make it happen - no. Just my 2p worth Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q4wWLJ080403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jul 2011 21:58:32 -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 p6Q4wWVY080402; Mon, 25 Jul 2011 21:58:32 -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-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6Q4wT1L080397 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Mon, 25 Jul 2011 21:58:31 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by eya28 with SMTP id 28so111565eya.21 for ; Mon, 25 Jul 2011 21:58:44 -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:subject :content-type:content-transfer-encoding; bh=sljlMajfcW6n1jndOjYWXmuspqNOjO0Cl+0l1VOAwQs=; b=otfpnPe5i0yfYLaXEIMcuHrhjUgzhA4RVFK6rQFRkR5HY/MoEU6tx+aEc5r9eC0ZvU zrmrAxxU7rGL1BPwC4pGSv/FJhZzaYDVgW/c82TXVGoNVAyqnZLv4ZXT34mJpxv22V2f h8g+wWOoUovWHDioxNfARNRtrPjRjxYkdC/xU= Received: by 10.204.23.74 with SMTP id q10mr1624895bkb.270.1311656324165; Mon, 25 Jul 2011 21:58:44 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id i14sm32722bkd.6.2011.07.25.21.58.42 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 21:58:43 -0700 (PDT) Message-ID: <4E2E49AC.9090207@gmail.com> Date: Tue, 26 Jul 2011 07:59:24 +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 Subject: POP handling commands given in wrong state 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, Post Office Protocol (POP) currently has no means of explicit indicating that the command is given in the wrong state. > A server MUST respond to a command issued when the > session is in an incorrect state by responding with a negative status > indicator. doesn't give enough information to the client. The -ERR response indicating wrong state may override -ERR response given with its natural meaning. I propose to define the new POP extension response code (RFC 2449), WRONG-STATE, to indicate this. Eg.: > C: > S: +OK server ready > C: STAT > S: -ERR [WRONG-STATE] Not in TRANSACTION state yet Any thoughts? Mykyta Yevstifeyev