Subject: Re: [Uri-review] Request to review draft-yevstifeyev-pops-uri-scheme-02

From: Chris Newman <[email-masked]>
Date: Tue, 15 Mar 2011 10:59:57 -0700

This document fails to provide and rules with respect to identity checks 
for TLS with the POP application. A reference to RFC 5246 is not sufficient 
as TLS leaves identity issues to the application. Examples of such rules 
are in RFC 2595 section 2.4 and 2.5. Or more recently, RFC 4513 section 
3.1.2, 3.1.3.

This document fails to state whether the POP server is in AUTHORIZATION 
state or TRANSACTION state upon conclusion of the SSL/TLS negotiation on 
the pops port.

Without such a statement in a standard document, the "pops" protocol is a 
non-interoperable protocol when client certificate authentication is used 
and thus is not suitable for standards track recognition.

If you state that the POP server is in AUTHORIZATION state after the TLS 
negotiation completes, even if a client certificate is supplied, then your 
document will be consistent with RFC 2595 and the EXTERNAL SASL mechanism 
can be used to enter TRANSACTION state, but the document will not 
necessarily be consistent with the majority behavior of de-facto pops 
implementations that support client certificates.

If you state that the POP server is in TRANSACTION state after the TLS 
negotiation completes if a valid client certificate was supplied and that 
the TLS negotiation MUST fail and/or the connection MUST be closed by the 
server if the client certificate is not valid, that means clients will have 
to implement RFC 2595 STLS if they wish to use an authorization identity 
different from the authentication identity.

		- Chris

--On March 15, 2011 17:34:09 +0200 Mykyta Yevstifeyev <[email-masked]> 
wrote:
> Hi,
>
> I'm writing to request a review of draft-yevstifeyev-pops-uri-scheme-02,
> that can be found here:
> http://tools.ietf.org/html/draft-yevstifeyev-pops-uri-scheme-02
>
> The document specifies the 'pops' URI scheme to designate the access to
> POP3 mailboxes available over secure TLS connections and may be
> considered to be appropriate for discussion here.
>
> Any comments directed to [email-masked]
> and copied to [email-masked] and [email-masked] are welcome.
>
> All the best,
> Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 16 Mar 2011 09:42:54 +0200

Chris,

Thanks for your comments.  See some responses in-line.

> are in RFC 2595 section 2.4 and 2.5. Or more recently, RFC 4513 section
IMO that procedure described in RFC 2595 apply to this case as well.
I suppose it can be added by normative reference in the next version.
> state or TRANSACTION state upon conclusion of the SSL/TLS negotiation on
It's considered that the user agent will enter AUTHORIZATION state
after TLS negotiation.  The case when it will be already in
TRANSACTION state is described in RFC 2595.
> implementations that support client certificates.
You mean the implementations of RFC 2595, while the proposed document
contains different POP3 over TLS binding at all.  The purpose of it is
to provide another procedure, not that described in 2595.

All the best,
Mykyta Yevstifeyev

---

From: Chris Newman <[email-masked]>
Date: Wed, 16 Mar 2011 10:59:25 -0700

> TRANSACTION state is described in RFC 2595.

There is no such case described for POP in RFC 2595. RFC 2595's POP section 
states:

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

>> negotiation completes, even if a client certificate is supplied, then
>> your document will be consistent with RFC 2595 and the EXTERNAL SASL 
mechanism
> contains different POP3 over TLS binding at all.

No. I mean existing implementations of pop3s (negotiating SSL/TLS at 
connection start on port 995 for POP). I believe Thunderbird and Outlook, 
for example, assume the server enters TRANSACTION state automatically when 
a valid client certificate is provided with the pop3s protocol.

> The purpose of it is

I understand. RFC 2595 section 7 attempted to discourage use of imaps and 
pop3s with reason. But reason rarely trumps deployment. So imaps and pop3s 
are deployed but not standardized protocols so there are some 
interoperability problems. We should accept they won't go away and document 
how they should interoperate. If your draft does that for pop3s, I consider 
it a welcome contribution to the RFC series.

While we're on the subject, I recommend your IANA considerations also 
updates the "pop3s" port registration to point to your document. That would 
be useful as your document will be the first time the "pop3s" protocol 
behavior is actually written down in a specification.

		- Chris

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 16 Mar 2011 20:57:53 +0200

16.03.2011 19:59, Chris Newman wrote:
> --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev 
> <[email-masked]> wrote:
> There is no such case described for POP in RFC 2595. RFC 2595's POP 
> section states:
>
However this depends on the implementation.  Since the pop3s protocol is 
not properly documented, some software might treat do in one way (enter 
the AUTHORIZATION state after the TLS handshake) while others might 
enter TRANSACTION state.  But now, when we're trying to document this 
protocol it's needed to be documented.  But this needs additional 
discussion.
> connection start on port 995 for POP). I believe Thunderbird and 
> Outlook, for example, assume the server enters TRANSACTION state 
> automatically when a valid client certificate is provided with the 
> pop3s protocol.
>
>> The purpose of it is
> I understand. RFC 2595 section 7 attempted to discourage use of imaps 
> and pop3s with reason. But reason rarely trumps deployment. So imaps 
> and pop3s are deployed but not standardized protocols so there are 
> some interoperability problems. We should accept they won't go away 
> and document how they should interoperate. If your draft does that for 
> pop3s, I consider it a welcome contribution to the RFC series.
>
> updates the "pop3s" port registration to point to your document. That 
> would be useful as your document will be the first time the "pop3s" 
> protocol behavior is actually written down in a specification.
OK, these concerns will be considered in the next version.

All the best,
Mykyta Yevstifeyev

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2011 09:40:47 +0000

Hi Chris,

> automatically when a valid client certificate is provided with the 

Interesting. Do they do the same when no client certificate is 
specified? I suspect the answer would be no, but I would like to double 
check.

> and document how they should interoperate.

Right.

> If your draft does that for pop3s, I consider it a welcome 
> contribution to the RFC series.
>

I was actually thinking the same. So Mykyta and I should add such text.