gmane.ietf.pop3ext

Administrative Sales Support - Virtual Office

2012-04-06T15:19:38

I would like to take this time to welcome you to our hiring process 
and give you a brief synopsis of the position's benefits and requirements.

If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.

Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 3000 EUR per month plus commission.

Region: Europe

Please note that there are no startup fees or deposits to start working for us.

To request an application form, schedule your interview and receive more information about this position 
please reply to Trinidad< at >eureseuropa.com,with your personal identification number for this position IDNO: 5690

Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Mykyta Yevstifeyev — 2011-08-25T09:17:24

24.08.2011 6:41, Chris Newman wrote:

Fine; fixed now.


When pointing to RFCs 2817 & 2818 after brief description of what these 
two ways mean, the reader can thus apply them to these references.  So 
I'll leave the current text (and I don't think it's a significant issue 
to have much discussion and debate).


Fixed.

Mykyta

Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Chris Newman — 2011-08-24T03:41:12

Only aesthetic editorial suggestions left, use if you wish...

--On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev <evnikita2< at >gmail.com> 
wrote:
for
the client

That works for me.

2595.

I can live with either text. But consider changing the final clause to: 
"establishing a TLS connection directly before the POP3 transaction". Note 
that "TLS" standards for "Transport Layer Security", so "Transport Layer 
Security layer connection" just sounds wrong to me, thus the suggestion to 
drop the redundant "layer".

negotiates
previously

Ok, how about this (to make the analogy appear in one place instead of a 
subordinate clause with a forward reference):

OLD:
     Two ways of protecting POP3 with TLS have been deployed (like 2 ways
     of securing HTTP [RFC2616]; see below).  The first includes
NEW suggestion:
     Two ways of protecting POP3 with TLS have been deployed similar to the
     two specified ways of protecting HTTP [RFC2616] with TLS described in
     RFC 2817 [RFC2817] and RFC 2818 [RFC2818]. T

Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Mykyta Yevstifeyev — 2011-08-23T05:07:33

Chris, all,

Chris agreed to co-author the document, so these are my responses from 
the "co-author's" point of view.

18.08.2011 3:39, Chris Newman wrote:

Here I concur with Alexey that SHOULD NOT is fine to add such sentence.


I'm fine with such change.


I'm OK to remove "updates RFC 1939".  However, the current abstract, 
compared with the proposed, seems to be clearer.


So this change seems OK.


The analogy with HTTP, I'm convinced, is very useful; however, some of 
the improvements you propose here will be incorporated.  (Later:) I've 
left the following text:

    Two ways of protecting POP3 with TLS have been deployed (like 2 ways
    of securing HTTP [RFC2616]; see below).  The first includes
    establishing TLS layer connection during the POP3 transaction (also
    known as upgrading to TLS) [RFC2595].  The other one involves
    establishing TLS connection directly before establishing POP3
    transaction.  Unlike the former, this way (called "POP3S" throughout
    this document) has not bee

Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Chris Newman — 2011-08-19T18:17:09

--On August 19, 2011 12:21:14 +0100 Alexey Melnikov 
<alexey.melnikov< at >isode.com> wrote:
for
the client

I'd be fine with a SHOULD NOT.

It's an important usability issue -- many clients pop up an intrusive 
"certificate selection dialog" if the server asks for a certificate. The 
NSS APIs support this check although the APIs to do so are difficult to use 
and non-obvious (you have to search for a cert with a client-certificate CA 
trust flag in the certificate db).

- Chris

Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Alexey Melnikov — 2011-08-19T11:21:14

Hi Chris,
My personal replies are (without consulting with Mykyta):

Chris Newman wrote:


I am wondering whether this is actually possible to enforce using 
existing TLS stacks. I would rather not make this a MUST NOT level 
requirement if there are no APIs for this in, for example, OpenSSL.



Yes, good point.


I am Ok with this change.


Ok.


Yes.


I like your rewording.


Ok.


Ok with me.


Sure.

Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Chris Newman — 2011-08-18T00:39:18


Add to section 2.1:

  Servers that lack configuration to accept an X.509 client certificate for
  authentication purposes MUST NOT send a CertificateRequest handshake to 
the client
  during TLS negotiation.

Also in section 2.1:

OLD:
   SHALL use some other way to identify itself, e.g. USER and PASS
   commands.
NEW:
   MAY close the connection or try a different authentication mechanism 
(e.g., USER
   and PASS commands).

It's a spec error to disallow a client configuration that requires use of 
client certificate authentication. For high security sites, a password 
fallback is not acceptable.


There are two general editorial problems: 1. issues that might cause 
problems during last call. 2. the text could be simplified in several 
places.

Here are some editorial suggestions:

In Abstract, OLD:
   This document specifies how the Post Office Protocol, Version 3
   (POP3) may be secured with Transport Layer Security (TLS) protocol,
   by establishing TLS layer connection directly before POP3
   trans

Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt

Mykyta Yevstifeyev — 2011-08-12T09:29:35

Hello all,

Based on discussions on this list, we have uploaded the new version of 
POP-over-TLS draft:


The HTML-ized link is 
http://tools.ietf.org/html/draft-melnikov-pop3-over-tls-01.  Please 
provide your further comments, copied to Alexey Melnikov (just use 
'Reply all').

Thanks,
Mykyta Yevstifeyev

Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

Paul Smith — 2011-08-09T15:15:01

On 09/08/2011 06:14, Mykyta Yevstifeyev wrote:
My view is that if a POP3 agent will be changed according to a new 
document, it should be changed to use authentication - even if it's SASL 
EXTERNAL, so 'WRONG-STATE' will never happen

If we are just documenting existing behaviour, then a 'WRONG-STATE' code 
is irrelevant as that is not in existing behaviour

So, either way the 'WRONG-STATE' code is no use.

Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

Mykyta Yevstifeyev — 2011-08-09T04:14:13

09.08.2011 0:59, Chris Newman wrote:

There already is.  When the client receives such response, it should 
change its state according to the server's one.  If client and a server 
are unsynchronized, WRONG-STATE response code will facilitate their 
synchronizing.

Mykyta

Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

Chris Newman — 2011-08-08T21:59:22

--On August 6, 2011 7:38:53 +0300 Mykyta Yevstifeyev <evnikita2< at >gmail.com> 
wrote:

Ok. So then why is the WRONG-STATE code useful enough to be worth the 
trouble to publish a document?

The litmus test that's been mostly followed for IMAP is that a response 
code is justified if the client can usefully behave differently as a result 
of the response code. Can you articulate how the client would usefully 
behave differently as a result of this code? If so, I suggest adding that 
explanation to the document.

- Chris

Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

Mykyta Yevstifeyev — 2011-08-06T04:38:53

05.08.2011 9:07, Chris Newman wrote:

Well, I'll change this.


This is clear from RFC 2449, but to be clearer, I'll mention this.


Well, in the case when we define a response code, a clear reason for 
issuing it should be stated.  For the STATE response code, there is no 
one.  With respect to POP3S.  After some discussions with Alexey we 
reached the agreement to follow RFC 1939, and state the following: (1) 
TLS negotiation --> /AUTHORIZATION/ (2) [due to client/server's 
settings] use SASL EXTERNAL --> (3) [if 2 fails, or there was no 
convention between client and server] authenticate itself --> 
/TRANSACTION/ (4) actual transaction.  So the response code for this 
purpose isn't useful any more.

Mykyta

Re: Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

Chris Newman — 2011-08-05T06:07:03

I see no reason for this to be experimental; it should be standards track. 
We have deployed protocols with similar error codes (including SMTP 503). 
It has not been harmful and has at least been helpful to debugging.

I think the specification should explicitly state that servers implementing 
WRONG-STATE MUST also advertise and implement the RESP-CODES capability 
from RFC 2449. That makes client parsing deterministic.

I think it would be helpful to state that a motivation for this document is 
to provide a way for deployed (non-standard) pop3s servers that support 
client certificate authentication to deterministically indicate whether or 
not the server accepted the client certificate in a way that also does not 
break backwards compatibility with deployed client software. That is a good 
reason for a new error code, and without a statement like that, it is not 
obvious this idea merits the cost of RFC publication. And informative 
reference to your pop3s specification may also be helpful for that pur

Re: POP handling commands given in wrong state

Alexey Melnikov — 2011-08-03T20:49:29

Mykyta Yevstifeyev wrote:
I strongly prefer documenting existing behaviour for POP3S (and document 
what is broken with it, if anything).
I don't think mandatory use of SASL EXTERNAL is necessarily the current 
practice. Other SASL mechanisms can be used on pop3s ports (at least in 
some server implementations).

Fwd: I-D Action: draft-yevstifeyev-pop-wrong-state-00.txt

Mykyta Yevstifeyev — 2011-08-04T03:57:06

Hello all,


The HTMLized version - 
http://tools.ietf.org/html/draft-yevstifeyev-pop-wrong-state-00.  Any 
comments are welcome, of course.

Mykyta Yevstifeyev

Re: POP handling commands given in wrong state

Mykyta Yevstifeyev — 2011-07-30T09:38:10

29.07.2011 17:21, Chris Newman wrote:

I actually have the same opinion, but in order to suit RFC 1939 
requirements, I think defining the mandatory use of SASL EXTERNAL 
mechanism after TLS-authenticated POP-over-TLS session establishment 
should resolve the issue.  Even if the server has authenticated the user 
upon TLS negotiation, formal authentication with RFC 5034 AUTH command 
using EXTERNAL mechanism will be obligatory to be preformed.


I also agree that STLS is a bit better that currently deployed 
POP-over-TLS, so we both concur here.


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.


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

Re: POP handling commands given in wrong state

Chris Newman — 2011-07-29T14:21:28

--On July 29, 2011 7:04:36 +0300 Mykyta Yevstifeyev <evnikita2< at >gmail.com> 
wrote:

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 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

Re: POP handling commands given in wrong state

Mykyta Yevstifeyev — 2011-07-29T04:04:36

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

Re: POP handling commands given in wrong state

Paul Smith — 2011-07-27T08:49:53

On 27/07/2011 05:57, Mykyta Yevstifeyev wrote:

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

Re: POP handling commands given in wrong state

Mykyta Yevstifeyev — 2011-07-27T05:05:18

26.07.2011 17:35, Randall Gellens wrote:
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: <authenticates itself>
C: USER foo
S: -ERR [WRONG-STATE/TRANSACTION] Already in TRANSACTION.
---
etc.

Mykyta

Re: POP handling commands given in wrong state

Mykyta Yevstifeyev — 2011-07-27T04:57:11

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.
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.
This assumes use of STLS, which performs TLS negotiation during POP3 
session.  POP-over-TLS deliberately makes use of TLS before POP session.
See above.  Server greeting = ServerHello TLS message; authentication = 
TLS negotiation.
They can't be anyway as some required steps of RFC 1939 are replaced by 
TLS steps.  This results in a modified protocol.
But if we try to unify all existing behavior, this will be great, won't it?

Mykyta Yevstifeyev