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

Chris Newman <chris.newman@oracle.com> Wed, 24 August 2011 17:40 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7OHevFT087429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 10:40:57 -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 p7OHevex087428; Wed, 24 Aug 2011 10:40:57 -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 p7OHetOi087401 for <ietf-pop3ext@imc.org>; Wed, 24 Aug 2011 10:40:56 -0700 (MST) (envelope-from chris.newman@oracle.com)
Received: from brmsunmail1-sfbay.uk.sun.com ([10.79.11.100]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p7OHeroK010470; Wed, 24 Aug 2011 17:40:53 GMT
Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by brmsunmail1-sfbay.uk.sun.com (8.14.4+Sun/8.14.4/ENSMAIL,v2.4) with ESMTP id p7OHeqOj012734; Wed, 24 Aug 2011 17:40:52 GMT
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.us.oracle.com (Oracle Communications Messaging Exchange Server 7u5-4.01 64bit (built May 4 2011)) with ESMTPA id <0LQG00028141TS00@gotmail.us.oracle.com>; Wed, 24 Aug 2011 10:40:52 -0700 (PDT)
Date: Tue, 23 Aug 2011 20:41:12 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Cc: ietf-pop3ext@imc.org, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Fwd: I-D Action: draft-melnikov-pop3-over-tls-01.txt
Message-id: <D26E39BC7394E13A0A88DBBA@96B2F16665FF96BAE59E9B90>
In-reply-to: <4E533595.2020907@gmail.com>
References: <4E44F27F.802@gmail.com> <688511DBDA04FDB2E5B1C431@96B2F16665FF96BAE59E9B90> <4E533595.2020907@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>

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

--On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev <evnikita2@gmail.com> 
wrote:
> 18.08.2011 3:39, Chris Newman wrote:
>>> From a technical viewpoint, I have two suggestions:
>>
>> 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.
>
> Here I concur with Alexey that SHOULD NOT is fine to add such sentence.

That works for me.

>> 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
>>   transaction.  It updates RFC 1939 and RFC 2595.
>> NEW:
>>   This document specifies use of Transport Layer Security (TLS) on
>>   port 995 to protect Post Office Protocol, Version 3. It updates RFC 
2595.
>>
>> Discussion: This no longer changes any rules in RFC 1939, so I see no
>> reason to update that specification -- perhaps best to avoid the
>> debates about "does this update spec XXX?" and "what does it mean for
>> a proposed standard to update a full standard?" during last call.
>
> I'm OK to remove "updates RFC 1939".  However, the current abstract,
> compared with the proposed, seems to be clearer.

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

>>   Two mechanisms to protect POP3 using TLS have been deployed. One 
negotiates
>>   TLS within POP3 (also known as upgrading to TLS) [RFC2595].  The other
>>   starts TLS prior to starting the POP3 application layer. The latter
>>   mechanism (called "POP3S" throughout this document) has not been 
previously
>>   specified in an RFC. This document specifies POP3S.
>
> 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:

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]. The first includes ...

> This might be considered that POP3S is a protocol that is different from
> POP3.  However, I'll try to change this sentence so that it gets shorter
> and clearer.  I think the following is fine:
>
>     After the client has received the +OK response to the authentication
>     command, they both enter TRANSACTION state.

How about:
     After the client has received the +OK response to the authentication
     command, both the client and server enter TRANSACTION state.

Otherwise looks good.

		- Chris