[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: POP handling commands given in wrong state
29.07.2011 17:21, Chris Newman wrote:
--On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev
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
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 -
(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
POP-over-TLS should or should not be used. POP-over-TLS isn't worse
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.