Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2MCtgJo060421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2011 05:55:42 -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 p2MCtgiF060420; Tue, 22 Mar 2011 05:55:42 -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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2MCtd7Y060407 for ; Tue, 22 Mar 2011 05:55:40 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 22 Mar 2011 12:55:37 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D886E9F.7020509@isode.com> Date: Tue, 22 Mar 2011 09:40:47 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Newman CC: Mykyta Yevstifeyev , draft-yevstifeyev-pops-uri-scheme@tools.ietf.org, uri-review@ietf.org, ietf-pop3ext@imc.org Subject: Re: [Uri-review] Request to review draft-yevstifeyev-pops-uri-scheme-02 References: <4D7F86F1.1070507@gmail.com> <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Chris, Chris Newman wrote: > --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev > wrote: > >> 2011/3/15, Chris Newman : >> >>> 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. >> >> 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. > > 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." > >>> 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. >> >> You mean the implementations of RFC 2595, while the proposed document >> 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. 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. >> The purpose of it is >> to provide another procedure, not that described in 2595. > > 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. Right. > 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. I was actually thinking the same. So Mykyta and I should add such text. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2GIvOdf028739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 11:57:24 -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 p2GIvOID028738; Wed, 16 Mar 2011 11:57:24 -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-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2GIvLwm028733 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 16 Mar 2011 11:57:23 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by bwz14 with SMTP id 14so2236596bwz.16 for ; Wed, 16 Mar 2011 11:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4s6omqZM6Nyy7tchB1V1/JY0hwlZaUL41qynP6U5t8Q=; b=uPZzXt8JawNiVI6Hznr5Wl+Om/TkXpDzzUY2HpGazm0I1RkUDUF6PmJ65Yr68k1Nln 1bSX8/yRDPIZsqaO4jehi9KxrlbtPu2kj3HlfXBxywGB/0SUmyhCUeqOq6UreS+SpyKV ddOGaKwaOtFCW8+myZQ1NQUFsugnmG72QgA+g= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=aHGQLC9xZEn2LDXqtHM5gF7y0IwOhOMriOZ3e0p2+QV4Lx0oN577MxWdoSSolZZ7KX /Q7n0Qc/Z/rs0MGhB5LR+HWVzDlnaEuY9IOgebBv3Rv8G9auJHuJVh2hJW/nawZ0GVs5 Q665CAxcu0Dp0tCf2lvmnIDBSmWE4P+6usAfs= Received: by 10.204.19.70 with SMTP id z6mr314819bka.204.1300301840866; Wed, 16 Mar 2011 11:57:20 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id w3sm828173bkt.17.2011.03.16.11.57.18 (version=SSLv3 cipher=OTHER); Wed, 16 Mar 2011 11:57:19 -0700 (PDT) Message-ID: <4D810831.9080600@gmail.com> Date: Wed, 16 Mar 2011 20:57:53 +0200 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Chris Newman CC: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org, ietf-pop3ext@imc.org, uri-review@ietf.org Subject: Re: Request to review draft-yevstifeyev-pops-uri-scheme-02 References: <4D7F86F1.1070507@gmail.com> <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 16.03.2011 19:59, Chris Newman wrote: > --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev > wrote: >> 2011/3/15, Chris Newman : >>> 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. >>> >> 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. > > 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." 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. > >>> 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. >>> >> You mean the implementations of RFC 2595, while the proposed document >> 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 >> to provide another procedure, not that described in 2595. > > 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. OK, these concerns will be considered in the next version. All the best, Mykyta Yevstifeyev > > - Chris > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2GHxYIR025363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 10:59:34 -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 p2GHxYSZ025362; Wed, 16 Mar 2011 10:59:34 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2GHxXSX025353 for ; Wed, 16 Mar 2011 10:59:33 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p2GHxWsZ014660 for ; Wed, 16 Mar 2011 17:59:32 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id p2GHxW7a006426 for ; Wed, 16 Mar 2011 10:59:32 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPA id <0LI50072CWN1PM00@gotmail.sfbay.sun.com> for ietf-pop3ext@imc.org; Wed, 16 Mar 2011 10:59:31 -0700 (PDT) Date: Wed, 16 Mar 2011 10:59:25 -0700 From: Chris Newman To: Mykyta Yevstifeyev Cc: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org, ietf-pop3ext@imc.org, uri-review@ietf.org Subject: Re: Request to review draft-yevstifeyev-pops-uri-scheme-02 Message-id: In-reply-to: References: <4D7F86F1.1070507@gmail.com> <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On March 16, 2011 9:42:54 +0200 Mykyta Yevstifeyev wrote: > 2011/3/15, Chris Newman : >> 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. >> > 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. 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." >> 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. >> > You mean the implementations of RFC 2595, while the proposed document > 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 > to provide another procedure, not that described in 2595. 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2G7gxq3087724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 00:42:59 -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 p2G7gxHo087723; Wed, 16 Mar 2011 00:42:59 -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-yi0-f43.google.com (mail-yi0-f43.google.com [209.85.218.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2G7gucv087718 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Wed, 16 Mar 2011 00:42:57 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by yia13 with SMTP id 13so659837yia.16 for ; Wed, 16 Mar 2011 00:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h7Gr5uZ/rS7fQFOkoANVn4A3Kw73E4jI3GhCifGMl3Q=; b=Vf4KBmbbisYROU0ENsmDmS7PPHechD3E4X2/PcdD+znxdCjU5165ak4T98b+ADToTS GJZufbD3dvsRg8lfa16ZGan+TqLHYbXCDOSs+2qEf9viZS+RAawJEihxZNzVf1M5VAC/ Ng3EHD9meT0o2QUJQR10frUVLz2O5coyESkAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qCI5rDja7kTR6/+LlmHiiDYzXQCj7yQdI6AF9gMUylNZuWn3iLfr8yydMC5BXk5zgs deB/ybyVB+YbqGTIdwNhpWfoRGNmHcHU98q/hJoeFxVu3lH7Q+pOlnG4UpI+NU0T77f8 v4CI1PmxktSEG9HSz7nuA/SJBFfnR1we1qwsE= MIME-Version: 1.0 Received: by 10.151.43.8 with SMTP id v8mr1001007ybj.296.1300261374081; Wed, 16 Mar 2011 00:42:54 -0700 (PDT) Received: by 10.150.219.5 with HTTP; Wed, 16 Mar 2011 00:42:54 -0700 (PDT) In-Reply-To: <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> References: <4D7F86F1.1070507@gmail.com> <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> Date: Wed, 16 Mar 2011 09:42:54 +0200 Message-ID: Subject: Re: Request to review draft-yevstifeyev-pops-uri-scheme-02 From: Mykyta Yevstifeyev To: Chris Newman Cc: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org, ietf-pop3ext@imc.org, uri-review@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Chris, Thanks for your comments. See some responses in-line. 2011/3/15, Chris Newman : > 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. > 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. > > 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. > 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. > > 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. > 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 > > 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 > 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 draft-yevstifeyev-pops-uri-scheme@tools.ietf.org >> and copied to ietf-pop3ext@imc.org and uri-review@ietf.org are welcome. >> >> All the best, >> Mykyta Yevstifeyev > > Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2FI0qgW059098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2011 11:00:52 -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 p2FI0qRS059097; Tue, 15 Mar 2011 11:00:52 -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 p2FI0MrW059056 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 15 Mar 2011 11:00:22 -0700 (MST) (envelope-from chris.newman@oracle.com) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id p2FI03hC013127 for ; Tue, 15 Mar 2011 18:00:21 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id p2FI03IO008537 for ; Tue, 15 Mar 2011 11:00:03 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.58.85] (dhcp-rmdc-twvpn-2-vpnpool-10-159-58-85.vpn.oracle.com [10.159.58.85]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPA id <0LI400F2C1ZX7J00@gotmail.sfbay.sun.com> for ietf-pop3ext@imc.org; Tue, 15 Mar 2011 11:00:03 -0700 (PDT) Date: Tue, 15 Mar 2011 10:59:57 -0700 From: Chris Newman To: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org, ietf-pop3ext@imc.org, uri-review@ietf.org Subject: Re: Request to review draft-yevstifeyev-pops-uri-scheme-02 Message-id: <6D07F4374764D58687F8B4B7@96B2F16665FF96BAE59E9B90> In-reply-to: <4D7F86F1.1070507@gmail.com> References: <4D7F86F1.1070507@gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 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 draft-yevstifeyev-pops-uri-scheme@tools.ietf.org > and copied to ietf-pop3ext@imc.org and uri-review@ietf.org are welcome. > > All the best, > Mykyta Yevstifeyev Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2FFXic7048680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Mar 2011 08:33:44 -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 p2FFXi7g048679; Tue, 15 Mar 2011 08:33: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 p2FFXgH6048674 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Tue, 15 Mar 2011 08:33:43 -0700 (MST) (envelope-from evnikita2@gmail.com) Received: by fxm3 with SMTP id 3so850055fxm.16 for ; Tue, 15 Mar 2011 08:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:reply-to:user-agent :mime-version:to:subject:content-type; bh=HD730dPjPJ0l3y9UdfTJac7VD6HDACPpQdBg21KjhGY=; b=azgbxkDCF0B4ib3xy9ehSxy4jg8pt2Kus+z7ngVZlH92lGo7HU6Q6zl7/OhrdLMqEJ ntl1VFcRQVfxc+mWsnx9gXj9t6MN2+zQynpDDsXKPPPFAUeexjrhDoBmIKIzIpSMeJwW oUqcUtpXExOfBHxuEhlofxwzpr3UeXu64ssSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type; b=HyIUpYIorOjk9gXibS80XnmY5SQQ+oFT1JHGVYzGwLmd7QQnTMfyq6NNZPTEynS0Pl Bm9/oa4n04C5To3Rli1NZq/543BUNeUzmc9q34kJohELq5WtWF/Qt3ttX15Yy6rrrUJJ XnZIB8DGDop1tiL0hXXo1W/zwYyzxx5s2u4hc= Received: by 10.223.6.11 with SMTP id 11mr1509341fax.93.1300203214920; Tue, 15 Mar 2011 08:33:34 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.134]) by mx.google.com with ESMTPS id n3sm436514fax.31.2011.03.15.08.33.33 (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 08:33:34 -0700 (PDT) Message-ID: <4D7F86F1.1070507@gmail.com> Date: Tue, 15 Mar 2011 17:34:09 +0200 From: Mykyta Yevstifeyev Reply-To: draft-yevstifeyev-pops-uri-scheme@tools.ietf.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: Request to review draft-yevstifeyev-pops-uri-scheme-02 Content-Type: multipart/alternative; boundary="------------060307010906080707070102" Sender: owner-ietf-pop3ext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------060307010906080707070102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 draft-yevstifeyev-pops-uri-scheme@tools.ietf.org and copied to ietf-pop3ext@imc.org and uri-review@ietf.org are welcome. All the best, Mykyta Yevstifeyev --------------060307010906080707070102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 draft-yevstifeyev-pops-uri-scheme@tools.ietf.org and copied to ietf-pop3ext@imc.org and uri-review@ietf.org are welcome.

All the best,
Mykyta Yevstifeyev
 --------------060307010906080707070102--