[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

--On August 23, 2011 8:07:33 +0300 Mykyta Yevstifeyev <evnikita2@xxxxxxxxx> 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