Re: POP handling commands given in wrong state
Chris Newman <chris.newman@oracle.com> Sat, 30 July 2011 03:59 UTC
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 <ietf-pop3ext@imc.org>; 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 <chris.newman@oracle.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>, 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
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: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>
--On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev <evnikita2@gmail.com> 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
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Chris Newman
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Randall Gellens
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Paul Smith
- Re: POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: POP handling commands given in wrong state Paul Smith
- POP handling commands given in wrong state Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Paul Smith
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Chris Newman
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Mykyta Yevstifeyev
- Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-… Chris Newman
- Re: POP handling commands given in wrong state Alexey Melnikov
- Fwd: I-D Action: draft-yevstifeyev-pop-wrong-stat… Mykyta Yevstifeyev