Re: POP handling commands given in wrong state

Mykyta Yevstifeyev <evnikita2@gmail.com> Fri, 29 July 2011 04:03 UTC

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 <ietf-pop3ext@imc.org>; Thu, 28 Jul 2011 21:03:43 -0700 (MST) (envelope-from evnikita2@gmail.com)
Received: by fxg17 with SMTP id 17so2969002fxg.16 for <ietf-pop3ext@imc.org>; 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 <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Paul Smith <paul@pscs.co.uk>
CC: ietf-pop3ext@imc.org, Alexey Melnikov <alexey.melnikov@isode.com>
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: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=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.
>
>
>
>