[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> Jeffrey M. Vinocur said:

>> I don't know why we didn't get a publication announcement, but I've 
>> released a new version of the TLS draft; comments please.
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-01.txt

> Section 2: it's not clear from this document why STARTTLS is forbidden
> after a successful authentication has been organised.

This is the way that STARTTLS is specified for other protocols.  I'm
curious too why this is, and would love to hear more details, but I think
it's important that we leave this in place.  We're trying to copy as
closely as possible how STARTTLS has been successfully deployed elsewhere.

I'm guessing it's related to the fact that authentication before STARTTLS
is pointless since it just has to be done again.

> Section 3.1: The responses should be split into two lists, as with POST in
> the base NNTP specification. 580 goes in the second list; the rest go in
> the first. That's because (as I understand it) you don't get a 580 until
> after a 382.

Agreed.

> Section 3.1: The sentence beginning "Clients MUST ..." should be removed,
> since the base specification states which responses must be expected.

Agreed.

> Section 3.2: I would delete the second sentence of the first paragraph,
> relying on the base specification, or at least the bit before the
> semicolon. We don't talk about sockets, just connections, and because
> the connection will switch to the TLS protocol, talking about sending
> anything else is premature.

I would delete the part before the semicolon but leave the rest of this,
since I think it's useful to make no pipelining explicit.

> Section 3.2.1: Rather than "... it SHOULD do at least one of (1) close
> ..."  I think you are better saying "... it SHOULD keep the connection
> [text of (2)] or MAY close the connection [text of (1)]". That is, make
> it clear that (2) is better.

Why is it obvious to you that (2) is better?  That's not clear to me; I'm
not sure which of those is better and would want some practical experience
first to be able to figure that out.

> Section 3.2.2: "... recovery *of the underlying NNTP connection* is
> possible ..." or something like that; make it clear you don't mean
> recovery of the TLS session.

Agreed.

> Section 3.2.2: The second paragraph is in error - it is *not* the state
> after the initial connection, but rather the state after the initial
> greeting has been sent. Therefore this paragraph becomes:

>     Upon successful completion of the TLS handshake, the NNTP protocol
>     is reset to the state immediately after the initial greeting
>     response line (see 5.1 of [NNTP]) has been sent; no such greeting
>     is sent and the next step is for the client to send a command.
>     The server MUST discard any knowledge obtained from the client,
>     such as the current newsgroup and article number, that was not
>     obtained from the TLS negotiation itself. The client MUST discard
>     any knowledge obtained from the server, such as the list of NNTP
>     service extensions, which was not obtained from the TLS negotiation
>     itself.

Agreed.

> Section 3.3: Please add an example that involves the 580 response
> followed by another command.

Agreed.

> Section 4: Delete the reference to the ABNF core rules, since I don't
> use them in [NNTP].

> Appendix: I suggest you add a formal specification similar to those in
> Appendix D of [NNTP].

Agreed.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>